Selamlar! Nasılsınız, iyi misiniz? Ben bugün size veritabanlarının olmazsa olmazlarından, hatta adeta temel taşları diyebileceğimiz o üç sihirli kelimeden bahsedeceğim: PRIMARY KEY, FOREIGN KEY ve UNIQUE. Hani bazen bir program yazarsın, her şey gayet güzel çalışıyordur, her şey yerli yerindedir… Sonra bir bakarsın, aynı kullanıcıyı iki kere kaydetmişsin! İşte o an “Eyvah!” dersin. İşte tam da bu gibi durumları önlemek için bu anahtar kelimeler var. Bana göre bu üçlü, bir veritabanının hem güvenliğini hem de doğruluğunu sağlayan süper kahramanlar gibidir.
Düşünsenize, koskoca bir şirketin müşteri bilgilerini tutan bir veritabanı var. Eğer aynı müşteriyi iki kere farklı ID’lerle kaydederseniz, ne olur? Bir sürü karmaşa, yanlış raporlar, belki de yanlış faturalar… İnanın ki bu tür hatalar hem zaman kaybı hem de ciddi maddi kayıplara yol açabilir. Bu yüzden bu kısıtlamaları doğru anlamak ve uygulamak çok önemli. Tabi bunu yaparken de işin içine biraz teknik detay giriyor ama hiç gözünüz korkmasın, anlatacağım.
Öncelikle PRIMARY KEY’den başlayalım. Bunu şöyle düşünün: Herkesin bir TC kimlik numarası var değil mi? İşte veritabanındaki her bir satırın da böyle benzersiz bir kimliği olmalı. PRIMARY KEY tam olarak bu işe yarıyor. Bir tablodaki her bir kaydı benzersiz bir şekilde tanımlayan sütun veya sütunlar grubudur. Bu anahtar hem NULL değer alamaz, hem de kendi içinde tekrarlanamaz. Yani bir ID numarası bir kere kullanıldıysa, bir daha asla aynı ID ile başka bir kayıt ekleyemezsin. Bu, veritabanındaki her bir girdinin kendine ait, eşsiz bir kimliği olmasını garantiliyor. Çok güzel değil mi?
Şimdi gelelim FOREIGN KEY’e. Bu biraz daha ilişkilere odaklanıyor. Hani bazen bir arkadaşınızın ailesini sorarsınız ya, işte FOREIGN KEY de tablolardaki ilişkileri kuruyor. Bir tablodaki bir sütun, başka bir tablonun PRIMARY KEY’ine referans veriyorsa, işte o sütun FOREIGN KEY olur. Mesela, ‘Siparişler’ tablonuz var ve bu siparişlerin hangi müşteriye ait olduğunu belirtmek istiyorsunuz. ‘Müşteriler’ tablosunda her müşterinin bir PRIMARY KEY’i (mesela ‘MusteriID’) olduğunu düşünün. ‘Siparişler’ tablosuna ekleyeceğiniz ‘MusteriID’ sütunu, ‘Musteriler’ tablosundaki ‘MusteriID’ye referans veren bir FOREIGN KEY olacaktır. Bu sayede, var olmayan bir müşteriye sipariş veremezsiniz. Yani, ‘Musteriler’ tablosunda olmayan bir ‘MusteriID’yi ‘Siparişler’ tablosuna eklemeye kalktığınızda, veritabanı size hata verir. Bu da veriler arasındaki tutarlılığı sağlıyor, yani iki tablo arasında mantıksal bir bağ kuruyor. Bu arada, bana göre bu FOREIGN KEY mantığı, gerçek hayattaki ilişkilere çok benziyor. Hani bir şeyi bağlamadan bir yere koyamazsın ya, işte o hesap.
Ve son olarak UNIQUE kısıtlaması. Bu da PRIMARY KEY’e benziyor ama biraz daha esnek. UNIQUE kısıtlaması olan bir sütun, NULL değer alabilir (genellikle bir tane NULL’a izin verilir, ama bu veritabanı sistemine göre değişebilir) ve kendi içinde benzersiz olmalıdır. Yani, bir e-posta adresiniUNIQUE olarak tanımladığınızda, aynı e-posta adresiyle birden fazla kullanıcı kaydedemezsiniz. Ama bu sütun PRIMARY KEY olmadığı için, bir kere NULL kullanıldıktan sonra birden fazla NULL değere izin verilebilir. PRIMARY KEY’in yaptığı gibi her satırı benzersiz olarak tanımlamak zorunda değil, sadece o sütundaki değerlerin tekrar etmemesini sağlıyor. Mesela bir kullanıcı adı da UNIQUE olabilir. Herkesin kendine özel bir kullanıcı adı olmalı, değil mi? Bu da verilerin tekrarlanmasını önlüyor, aslında gayet basit bir mantığı var.
Bu arada, bu kısıtlamaları bir veritabanı oluştururken ya da mevcut bir tabloya eklerken tanımlayabiliyorsunuz. Örneğin, PostgreSQL’de şöyle bir tablo oluşturduğunuzu düşünün:
“`sql CREATE TABLE Musteriler ( MusteriID SERIAL PRIMARY KEY, Ad VARCHAR(50) NOT NULL, Soyad VARCHAR(50) NOT NULL, Email VARCHAR(100) UNIQUE, OlusturmaTarihi TIMESTAMP DEFAULT CURRENT_TIMESTAMP );
CREATE TABLE Siparisler ( SiparisID SERIAL PRIMARY KEY, MusteriID INT, SiparisTarihi DATE, ToplamFiyat DECIMAL(10, 2), FOREIGN KEY (MusteriID) REFERENCES Musteriler(MusteriID) ); “`
Bu kodda ne yaptık peki? ‘Musteriler’ tablosunda ‘MusteriID’yi PRIMARY KEY yaptık, yani her müşteri için benzersiz bir numara. ‘Email’ sütununu ise UNIQUE yaptık, böylece aynı e-posta ile birden fazla kişi kaydedilemez. ‘Siparisler’ tablosunda ise ‘SiparisID’ PRIMARY KEY, ama asıl olay ‘MusteriID’ sütununda. Bu sütunu, ‘Musteriler’ tablosundaki ‘MusteriID’ye FOREIGN KEY olarak bağladık. Yani, ‘Siparisler’ tablosuna bir sipariş eklerken, eğer ‘Musteriler’ tablosunda olmayan bir ‘MusteriID’ girerseniz, sistem size hata verecektir. Bu gerçekten de verilerinizi korumanın en temel yollarından biri.
Şimdi gelelim benim başıma gelen bir olaya… Bir zamanlar, lisedeyken falan olsa gerek, basit bir not defteri uygulaması yapıyordum. O zamanlar ne SQL biliyordum ne de bu kısıtlamalardan haberim vardı. Her şeyi dümdüz bir metin dosyasına kaydediyordu. Bir gün, bir arkadaşımın doğum gününü hatırlayıp uygulamaya “Mehmet’in Doğum Günü” diye bir not ekledim. Sonra bir daha ekledim, çünkü ilkini yanlış kaydettiğimi düşündüm. Sonuç? Dosyanın içinde “Mehmet’in Doğum Günü” diye iki tane aynı satır oldu. Hani biraz absürt değil mi? O zamanlar bunun ne kadar büyük bir problem olabileceğini pek düşünmemiştim ama şimdi anlıyorum ki, eğer o basit not defteri bir veritabanı olsaydı, işte o zaman işler çığrından çıkardı.
Bu kısıtlamalar sayesinde veritabanı yönetimi çok daha kolaylaşıyor ve verilerin doğruluğu artıyor. Veritabanı tasarlarken bu üç anahtarı göz önünde bulundurmak, ileride yaşanacak birçok sorunun önüne geçecektir. Mesela, bir ürünü satan bir e-ticaret sitesi düşünün. Eğer ürün ID’si PRIMARY KEY ise, aynı ürünü iki kere ekleyemezsiniz. Eğer ürünleri kategorilere ayırıyorsanız, kategori ID’sini FOREIGN KEY yaparak, olmayan bir kategoriye ürün atayamayacağınızdan emin olursunuz. Ve tabii ki, ürün adı gibi alanları UNIQUE yaparak, aynı isimde iki farklı ürününüz olmasının önüne geçebilirsiniz. Bu arada, Trendyol veya Hepsiburada gibi sitelerin bu tür kısıtlamaları kullandığına eminim. Yoksa o kadar ürünü nasıl yönetirlerdi ki?
Sonuç olarak, PRIMARY KEY, FOREIGN KEY ve UNIQUE, veritabanı tasarımının olmazsa olmazları. Bunlar, verilerinizin bütünlüğünü, doğruluğunu ve tutarlılığını sağlamak için varlar. Kendi projelerinizde bu kısıtlamaları doğru bir şekilde kullanmak, size gelecekte büyük dertler açabilecek hatalardan kurtaracaktır. Bu üçlüye iyi bakın, onlar da size veritabanı konusunda hep iyi davranacaktır 🙂