Veritabanı ve SQL temelleri

Neden bir metin dosyası yetmiyor?

Kullanıcı kayıtlarını bir metin dosyasında tutabilirsiniz ve yüz satır için bu gayet iyi çalışır. Üç şey onu kırar ve üçü de ilk ay içinde ortaya çıkar.

Birincisi eşzamanlılık: iki kişi aynı anda kaydolduğunda iki program tek bir dosyaya yazmaya çalışır ve iki yazımdan biri kaybolur. İkincisi arama: belirli bir e-postaya sahip kullanıcıyı bir dosyada bulmak, dosyanın tamamını okumak demektir ve dosya büyüdükçe yavaşlar. Üçüncüsü doğruluk: bir metin dosyasında hiçbir şey aynı e-postayla iki kullanıcının kaydedilmesini engellemez.

Veritabanı, bu üçünü çözen bir programdır: eşzamanlı yazımlar için kilitleme, hızlı arama için dizinler ve geçersiz verinin hiç girmemesi için kısıtlar. Onunla bir dosya kaydedilsin diye konuşmazsınız; bu üç garantiyi almak için konuşursunuz.

Daha az söylenen bir nokta: veritabanı dosyaların yerini almaz. Görseller, videolar ve indirilebilir dosyalar genelde diskte kalır ve tabloya yalnızca adresleri kaydedilir. WordPress de böyle çalışır; veritabanı yedeğinin tek başına sitenin yedeği olmamasının nedeni budur.

Tablo, satır, sütun ve şu id sütunu

Bir tablo hesap tablosundaki bir sayfaya benzer: sütunlar neyin saklandığını söyler ve her satır bir kayıttır. Kullanıcılar tablosunda id, ad ve e-posta sütunları vardır ve her satır bir kullanıcıdır. Buraya kadar karmaşık bir şey yok.

Ama id sütununun özel bir rolü var ve adı birincil anahtar: tablo genelinde benzersiz ve asla değişmeyen bir değer. Var olma nedeni, başka hiçbir şeye güvenilememesidir; insanların adları tekrarlanır, e-postalarını değiştirir, telefonlarını kaybederler. Bu yüzden siparişler müşterinin adını değil id'sini tutar ve bu başvuruya yabancı anahtar denir.

Şimdi yaygın bir varsayımı kıran gerçek bir örnek. Bu sitenin WordPress'in posts dediği ana tablosunda, bu dersin denetlendiği gün 784 satır vardı; ama o 784 satır 24 farklı türde şeydi: 263 blog yazısı, 240 medya dosyası, 37 sayfa ve gerisi projeler, mesajlar, ilanlar ve birkaç şey daha.

Bu sayıdaki ders herkesin işine yarar: bir tablo bir biçimdir, bir konu değil. Aynı sütunlara ihtiyaç duyan her şey aynı tabloda oturabilir ve bir sütun daha ile geri kalandan ayrılabilir. Pratik sonucu şu: böyle bir tabloda koşulsuz bir SELECT, size birbiriyle ilgisiz dört şeyin karışımını verir.

İşin çoğunu yapan üç komut

SQL bir istek dilidir, adım adım talimat verme dili değil. Nasıl arayacağını söylemezsiniz; ne istediğinizi söylersiniz ve yolu veritabanı kendisi seçer.

SELECT name, email FROM users WHERE city = 'Tehran';

INSERT INTO users (name, email, city) VALUES ('Maryam', 'm@example.com', 'Shiraz');

UPDATE users SET city = 'Isfahan' WHERE id = 42;

Bu üç satırda görülmeye değer üç şey var. SELECT hangi sütunları, FROM hangi tablodan, WHERE hangi satırları der. Sütunları bilmiyorsanız SELECT * hepsini getirir; bu, etrafa bakmak için iyi, program kodunun içinde ise kötü bir alışkanlıktır, çünkü bir sütun eklendiği gün programınız beklemediği bir şey alır.

Bu sayfadaki en tehlikeli kelime, yokluğuyla, o WHEREdir. UPDATE users SET city = 'Isfahan'; bir söz dizimi hatası değildir; tamamen geçerlidir ve bütün kullanıcıların şehrini değiştirir. Hem MySQL hem MariaDB belgeleri bunu açıkça yazar ve ikisinin de böyle bir ifadeyi reddeden bir kipi vardır.

Bunu çözen alışkanlık bir satır fazla yazmaktır: her UPDATE ya da DELETE ifadesini önce aynı koşulla bir SELECT olarak yazın ve kaç satır döndüğüne bakın. O sayı beklediğiniz değilse koşulunuz yanlıştır ve bunu veriler gittikten sonra değil, şimdi öğrenmiş olursunuz.

Veritabanı ile önbelleği karıştırmayın

Bu sunucuda yan yana çalışan ve işleri tümüyle farklı olan iki şey var. Biri, MySQL ailesinden gelen ve sitenin kalıcı verilerinin tamamını tutan MariaDB. Öteki, az önce veritabanına sorulan soruların sonuçlarını bellekte tutan ve bir sonraki isteğin aynı şeyi yeniden sormasını önleyen bir nesne önbelleği olan Redis.

Aralarındaki fark tek cümleye sığar: önbelleği tümüyle silersek hiçbir şey kaybolmaz, yalnızca sonraki birkaç istek yavaşlar, çünkü her şey veritabanından yeniden kurulur. Veritabanını kaybedersek her şey gitmiştir.

Bu tek cümleden her yerde işinize yarayacak pratik bir kural çıkar: bir şeyi asla yalnızca önbellekte tutmayın. Önbelleğin her an boş olma hakkı vardır; ister yeniden başlatmadan ister bellek dolduğu için. Bir değerin önbellekte olmasına güvenen program, o değerin olmadığı gün hata verir. Önbellek hız içindir, saklamak için değil.

Aynı ayrım barındırma kararlarını da netleştirir: veritabanı hızlı disk ve düzenli yedek ister, önbellek bellek ister. Kendi kurduğumuz WordPress barındırmasında ikisi yan yana durur, ama ikisinden yalnızca biri yedeklenir ve olması gereken de tam olarak budur.

Bir sorguyu güvenli kılan nedir?

Veritabanıyla çalışırken yapılan en tehlikeli hata, sorguyu kullanıcının yazdığı metni yapıştırarak kurmaktır. Bir SQL ifadesi iki parçadan, kullanıcının metni ve sizin komutunuzdan, oluştuğunda veritabanının hangi kısmın veri hangisinin talimat olduğunu anlamasının yolu yoktur. Bu güvenlik açığı sınıfına SQL enjeksiyonu denir.

Çözümü eski, basit ve her yerde aynıdır: sorgu metninde değerin geleceği yere bir yer tutucu koyun ve değeri ayrıca teslim edin. O zaman kullanıcının yazdığı şey, kendisi bir SQL ifadesine benzese bile, yalnızca bir dizge olarak okunur. WordPress'te wpdb nesnesindeki prepare metodu tam olarak bunu yapar ve WordPress'in kendi belgeleri, kullanıcı girdisi taşıyan her sorgudan önce onu zorunlu sayar.

Burada size zaman kazandıracak pratik bir not: çoğu projede ham SQL hiç yazmazsınız. WordPress'in ve çerçevelerin, sorguyu sizin için ve güvenli biçimde kuran bir katmanı vardır. SQL bilmek, o katmanın ne ürettiğini ve neden yavaş olduğunu anlamanız içindir; her sorguyu elle yazmanız için değil.