Soru Kompozit Primer anahtar vs ek “ID” sütunu mu?


Böyle bir masamız olsaydı:

Kitaplar ("ISBN" ifadesini mevcut değil)

  • Yazar
  • Başlık
  • Baskı
  • Yayın yılı
  • Fiyat

Bir kişi {Yazar, Başlık, Basım) 'ın bir aday / birincil anahtar olabileceğini iddia edebilir.

Aday / birincil anahtarın {Yazar, Başlık, Basım} olması gerekip gerekmediğini veya bir Kimlik sütununun kullanılması gerekip gerekmediğini, {Yazar, Başlık, Basım) ile benzersiz bir dizin / anahtar kısıtlaması olup olmadığını ne belirler?

Yani

  • Yazar (PK)
  • Başlık (PK)
  • Baskı (pk)
  • Yayın yılı
  • Fiyat

daha iyi veya:

  • ID (PK)
  • Yazar
  • Başlık
  • Baskı
  • Yayın yılı
  • Fiyat

{Author, Title, Edition} nerede ek benzersiz bir dizin / kısıtlamadır?


32
2018-01-29 17:09


Menşei


Dupe olmak: stackoverflow.com/questions/1383062/composite-primary-key. Ayrıca okumak stackoverflow.com/questions/337503/... - MikeSmithDev
"Doğal vs vekil anahtarları" ya da benzer bir şey arayın. Bu konuda birçok tartışma. - Tim Lehner
Bu birçok kez tartışıldı, örneğin: İşte, İşte ve İşte. - Branko Dimitrijevic


Cevaplar:


Şunu söyle {Author,Title,Edition} Bir kitabı benzersiz olarak tanımlar, ardından aşağıdakiler tutar:

  1. Bu (süper) bir anahtar - bir tuple (satır) benzersiz bir şekilde tanımlar.

  2. Bu indirgenemez - herhangi bir sütun kaldırmak artık bir anahtar haline getirmez.

  3. Bu bir aday anahtardır - indirgenemez bir anahtar aday anahtardır.

Şimdi kimliği ele alalım (integer)

Buna sebep olabilirim Book Tablo anahtarı, yabancı bir anahtar olarak birkaç tabloda ve birkaç endekste görünecektir. Yani, bu oldukça fazla yer kaplayacak - üç sütun x 40 karakter (ya da her neyse ...) - bu tabloların her birinde artı eşleşen dizinlerde.

Bu "diğer" tabloları ve indeksleri küçültmek için benzersiz bir tamsayı-sütun ekleyebilirim. Book yabancı anahtar olarak adlandırılacak bir anahtar olarak kullanılacak tablo. Şöyle bir şey söyle:

alter table `Book` add `BookID` integer not null identity;

İle BookID benzersiz olmalı (olmalı) Book şimdi masa iki aday tuşa sahiptir.

Şimdi seçebilirim BookID birincil anahtar olarak.

alter table Book add constraint pk_Book primary key (BookID);

Ancak {Author,Title,Edition}  şart için bir anahtar (benzersiz) kalmak önlemek böyle bir şey:

BookID  Author      Title           Edition
----------------------------------------------- 
  1      C.J.Date  Database Design     1
  2      C.J.Date  Database Design     1

Özetlemek için BookID - ve birincil olarak seçerek - durmadı {Author,Title,Edition} (aday) anahtar olmak. Hala kendine özgü bir kısıtlaması ve genellikle eşleşen endeksi olmalıdır.

Ayrıca tasarım noktasından bu kararın "fiziksel seviye" üzerinde yapıldığı da dikkate alınmalıdır. Genel olarak, tasarımın mantıksal düzeyinde, bu ID mevcut değil - sütun boyutları ve dizinleri dikkate alınarak tanıtıldı. Böylece fiziksel şema mantıksaldan türetildi. DB boyutuna, RDBMS'ye ve kullanılan donanıma bağlı olarak, bu boyut mantığının hiçbirinin ölçülebilir bir etkisi olmayabilir. {Author,Title,Edition} Bir PK olarak mükemmel şekilde iyi bir tasarım olabilir - farklı olarak kanıtlanana kadar.


33
2018-01-29 20:04





Genel olarak, birincil anahtarın değeri değiştirmesini istemezsiniz. Bu nedenle kör veya vekil birincil anahtarlar kullanılır.

Kitap tablonuzu Yazar'la birincil anahtarın bir parçası olarak oluşturduğunuzu varsayalım.

Yaklaşık bir yıl sonra "Ray Bradbury" yi yanlış yazdığını öğrendiğini varsayalım. Ya da daha da kötüsü, "Rachael Bloom" kelimesini yanlış yazmışsın. Sadece yazım hatalarını düzeltmek için kaç tane veritabanı satırında değişiklik yapmanız gerektiğini hayal edin. Sadece kaç dizin referansının değiştirilmesi gerektiğini hayal edin.

Ancak, bir vekil anahtarı olan bir Yazar tablonuz varsa, yalnızca bir satırı düzeltmeniz gerekir. Hiçbir endeks değiştirilmemelidir.

Son olarak, veritabanı tablosu adları çoğul (Kitaplar) yerine genellikle tekildir (Kitap).


11
2018-01-29 17:18



Tekil ve çoğul hakkında katılmıyorum (bir tablo, sadece bir satır olsa bile, bir dizi bir dizi (ör. "Kitap") içerir). Fakat bu tamamen farklı bir öznel argüman ve burada IMHO'ya ait değil. - Aaron Bertrand
Vekil dediğinizde ID / ISBN kullanacak olanı mı kastediyorsunuz? - user997112
Kitaplarla ilgisi olmayan birincil anahtar demek istiyorum. Genel olarak, sıfırdan başlayan ve eklenen her satır için birer birer artan bir tamsayıdır. Ben onlara kör anahtarlar derim. - Gilbert Le Blanc
@AaronBertrand Singular, ER modellemede kabul edilen bir sözleşmedir (örneğin, "tekil" için arama ERwin Yöntemleri Kılavuzu). Ayrıca, OOP'taki sınıf isimleri, birçok kez potansiyel olarak örneklendirilebilecek olsa bile, tekildir. Ama bunun bir şekilde öznel olduğunu ve farklı bir kongre kullandığını kabul ediyorum, kesinlikle bir kardinal günah değil ... - Branko Dimitrijevic
Gilbert'le aynı fikirdeyim. Neredeyse her zaman, anahtar olabilecek başka bir şey var gibi göründüğünde bile bir çeşit satır tanımlayıcısı (genellikle bir int kimlik sütunu) eklerim. Şuna bakın - kullanıcı adı = 'jr33s22dt6uwwdrrws33ww' kullanıcılarını daha kolay güncellemek veya kullanıcılarını güncellemek nerede userid = 4 - Jeff B


Birincil ana anahtar senaryosunun kullanılması için bir başka iyi sebep ise, teklik kısıtının gelecekte değişmesidir (örneğin, bir kitabı benzersiz yapmak için ISBN'nin eklenmesi gerekir). Verilerinizi karşılayabilmek çok daha kolay olacak.


5
2018-01-29 21:30





Bununla ilgili birçok makale var. Durumunuzda kompozit anahtar ile ilgili sorunlar:

  1. kitapları diğer varlıklar ile bağlamak zor
  2. Çoğu ızgara, kompozit anahtarları (ör. Kendo grid, jqgrid) desteklemediğinden, onları bir ızgarada düzenlemek zor
  3. Yazar, Başlık, Sürümü yanlış yazabilirsin

Verilerinizi normalize etmek ve önerilen bir kimliğe (dasblinkenlight) sahip olmak için sadece bir kimlik depolamak da iyi olacaktır. En kötü durum senaryosu, onun ismini değiştirecektir (örneğin, onun evlendiğini ve yeni ismini sevdiğini).


3
2018-01-29 17:29