Foreign Key (FK) "bire" tarafındaki tabloda bulunsaydı, şu problemlerle karşılaşırdık:
1. Çok Sayıda Kolon (Boş Alan) Olurdu
Her "bire" (Class) kaydı, kendisiyle ilişkili birden fazla "çok" (Student) kaydını referans almak zorunda kalırdı.
Örneğin, "Class" tablosuna öğrencileri eklemeye çalışsaydık:
Id | Name | Student1 | Student2 | Student3 | Student4 | ... |
---|---|---|---|---|---|---|
1 | 10A | 1 | 2 | NULL | NULL | ... |
2 | 10B | 3 | NULL | NULL | NULL | ... |
- Kaç öğrenci olacağını bilemeyeceğimiz için kolon sayısı sabit olamazdı.
- Yeni bir öğrenci eklemek için Class tablosunun şemasını değiştirmemiz gerekirdi.
- NULL değerler içeren gereksiz kolonlar oluşurdu.
2. Veritabanı Normalizasyonu Bozulurdu
Veritabanı tasarımında 1. normal form (1NF) gereği, bir alan (kolon) sadece tek bir değeri içermelidir.
- FK, "bire" tarafında olursa, bir kolon birden fazla değeri tutamaz.
- Bu nedenle çok tarafındaki satırları bireye bağlamak zorundayız.
3. Sorgular Karmaşıklaşır ve Performans Düşer
Normalde ClassId üzerinden öğrencilere ulaşmak hızlı ve kolay olur. Ancak:
- "Bire" tarafına FK koyarsak, belirli bir öğrenciye hangi sınıfın ait olduğunu sorgulamak daha zor olur.
- JOIN işlemleri daha karmaşık hale gelir ve performans kaybı yaşanır.
Sonuç:
Foreign Key (FK), "çok" tarafında olmalıdır!
📌 Çünkü:
✅ "Bire" tarafında FK olursa tasarım bozulur, gereksiz kolonlar oluşur, veri tekrarı olur ve performans düşer.
✅ "Çok" tarafında FK olursa her kayıt yalnızca 1 FK tutar, esnek olur ve sorgular hızlı çalışır.
Eğer tersini uygulayan bir veritabanı ile karşılaşırsan, yanlış bir tasarım olabilir ve düzeltilmesi gerekebilir. 😃
Top comments (0)