İki masam var:
Şu anda bu yaklaşımı kullanıyorum: Her Profil kaydında Kullanıcı tablosuna bağlanan yabancı anahtar olarak "userId" adlı bir alan var . Bir kullanıcı kaydolduğunda Profil kaydı otomatik olarak oluşturulur.
Arkadaşımın önerisiyle kafam karıştı: "userId" alanını yabancı ve birincil anahtar olarak almak ve "profileId" alanını silmek. Hangi yaklaşım daha iyidir?
Yanıtlar:
Yabancı anahtarlar hemen hemen her zaman "Yinelemelere İzin Ver" şeklindedir, bu da onları Birincil Anahtarlar olarak uygunsuz hale getirir.
Bunun yerine, tablodaki her kaydı benzersiz şekilde tanımlayan bir alan bulun veya birincil anahtar olarak işlev görmesi için yeni bir alan (otomatik artan tam sayı veya GUID) ekleyin.
Bunun tek istisnası olan tablolardır bire-bir ilişki, yabancı anahtar ve birincil bağlantılı tablonun anahtar bir ve aynıdır.
Birincil anahtarların her zaman benzersiz olması gerekir; tablo bire çok ilişkiyse yabancı anahtarların benzersiz olmayan değerlere izin vermesi gerekir. Tablo bire çok ilişki ile değil, bire bir ilişki ile bağlanmışsa, birincil anahtar olarak yabancı anahtarı kullanmak tamamen iyidir. Aynı kullanıcı kaydının 1'den fazla ilgili profil kaydına sahip olma olasılığına sahip olmasını istiyorsanız, ayrı bir birincil anahtar kullanın, aksi takdirde sahip olduğunuza bağlı kalın.
Evet, yabancı anahtar olan bir birincil anahtara sahip olmak yasaldır. Bu nadir bir yapıdır, ancak şunlar için geçerlidir:
1: 1 ilişki. İki tablo, farklı izinler ve ayrıcalıklar nedeniyle yalnızca tablo düzeyinde geçerli olduğundan tek bir tablo içinde birleştirilemez (2017 itibariyle, böyle bir veritabanı tuhaf olacaktır).
1: 0..1 ilişkisi. Profil, kullanıcı türüne bağlı olarak mevcut olabilir veya olmayabilir.
performans bir sorundur ve tasarım bir bölüm olarak işlev görür: profil tablosuna nadiren erişilir, ayrı bir diskte barındırılır veya kullanıcılar tablosuyla karşılaştırıldığında farklı bir parçalama politikasına sahiptir. Altını çizen depolama sütunluysa mantıklı olmaz.
Bire bir ilişkiye sahip olmak genellikle kötü bir uygulama olarak kabul edilir. Bunun nedeni, verileri tek bir tabloda temsil edip aynı sonucu elde edebilmenizdir.
Ancak, referans yaptığınız tabloda bu değişiklikleri yapamayabileceğiniz durumlar vardır. Bu durumda Yabancı anahtarın birincil anahtar olarak kullanılmasıyla ilgili bir sorun yoktur. Otomatik olarak artan benzersiz birincil anahtardan ve yabancı anahtardan oluşan bir bileşik anahtara sahip olmak yardımcı olabilir.
Şu anda kullanıcıların oturum açabilecekleri ve bir uygulamayla kullanmak için bir kayıt kodu oluşturabilecekleri bir sistem üzerinde çalışıyorum. İçeri girmeyeceğim nedenlerden dolayı, kullanıcılar tablosuna gerekli sütunları ekleyemiyorum. Bu yüzden kod tablosu ile bire bir rotaya gidiyorum.
Evet, bu tablolar arasında bire bir ilişki olması durumunda yabancı anahtar birincil anahtar olabilir
Bunu yapmazdım. Ben tutacak profileIDtablonun birincil anahtarıProfile
Yabancı anahtar, iki tablo arasında yalnızca bir başvuru kısıtlamasıdır
Diğer tablolardan kendisine başvuran herhangi bir yabancı anahtarın hedefi olarak birincil anahtarın gerekli olduğu ileri sürülebilir. Yabancı anahtar, herhangi bir tablodaki bir veya daha fazla sütun kümesidir (tablonun birincil anahtarı bir yana, bir aday anahtar olması gerekmez) ve bazılarının birincil anahtar sütunlarında bulunan değerleri tutabilir. diğer masa. Yani yabancı anahtarla eşleşecek bir birincil anahtara sahip olmamız gerekir. Yoksa yapmalı mıyız? Birincil anahtar / yabancı anahtar çiftindeki birincil anahtarın tek amacı, kesin bir birleştirme sağlamaktır - başvurulan birincil anahtarı tutan "yabancı" tabloya göre bilgi tutarlılığını korumaktır. Bu, yabancı anahtarın başvurduğu değerin her zaman geçerli (veya izin verilirse boş) olmasını sağlar.
İşe ve sisteme bağlıdır.
Kullanıcı kimliğiniz benzersizse ve her zaman benzersiz olacaksa, userId'yi birincil anahtarınız olarak kullanabilirsiniz. Ancak sisteminizi genişletmek isterseniz, işleri zorlaştıracaktır. Tablo profiline yabancı anahtar eklemek yerine tablo profiliyle ilişki kurmak için tablo kullanıcısına yabancı anahtar eklemenizi öneririm.
Kısa cevap: BAĞIMLI .... Bu özel durumda, sorun olmayabilir. Ancak uzmanlar hemen hemen her seferinde buna karşı tavsiyede bulunacaktır; davanız dahil.
Neden?
Anahtarlar, söz konusu tabloya yabancı olduklarında (başka bir tablodan kaynaklandıklarında) tablolarda nadiren benzersizdir. Örneğin, bir öğe kimliği bir ÖĞE tablosunda benzersiz olabilir, ancak SİPARİŞLER tablosunda olmayabilir, çünkü aynı türden bir öğe büyük olasılıkla başka bir sırada var olacaktır. Benzer şekilde, SİPARİŞLER tablosunda sipariş kimlikleri benzersiz olabilir (olabilir), ancak birden çok satır öğesi içeren bir siparişin var olabileceği ORDER_DETAILS gibi başka bir tabloda olmayabilir ve belirli bir siparişte belirli bir öğeye karşı sorgulama yapmak için ikisinin birleştirilmesi gerekir Bu tablonun PK'si olarak FK (order_id ve item_id).
Ben DB uzmanı değilim, ancak mantıksal olarak PK'nız olarak otomatik oluşturulan bir değere sahip olmayı haklı çıkarabilirseniz, bunu yapardım. Bu pratik değilse, iki (veya belki daha fazla) FK'nin bir araya getirilmesi PK'niz olarak hizmet edebilir. AMA, tek bir FK değerinin PK olarak gerekçelendirilebileceği herhangi bir durum düşünemiyorum.