Her masada tek alanlı bir vekil / yapay birincil anahtar olmalı mı?

Genel olarak vekil / yapay anahtarların bir faydasını anlıyorum - değişmezler ve bu çok uygun olabilir. Bu, 'yapay' oldukları sürece tekli mi yoksa çoklu alan mı olduğu doğrudur.

Bununla birlikte, bazen her tablonun birincil anahtarı olarak otomatik artan bir tamsayı alanına sahip olmak bir politika meselesi gibi görünmektedir. Böyle bir tek alanlı anahtara sahip olmak her zaman en iyi fikir midir ve neden (ya da neden olmasın)?

Açıkçası, bu soru yapay ve doğal olanlarla ilgili değil - tüm yapay anahtarların tek alanlı olması gerekip gerekmediği ile ilgili.

Hayır diyeceğim , her zaman değil ama çoğu zaman evet. .

Bunlar bir vekil veya yapay anahtara gerek duymamanız gereken durumlar:

• Saf kavşak tabloları . Yoksa hiçbir yabancı anahtarın ve eğer hedef olma kesişme riski çok az veya bağımsız özelliklerini (FK adlı iki ebeveyn tablolara dışındaki yani bir şey) çeken kavşak riski o zaman kombinasyonunu kullanarak kurtulabiliriz PK olarak FK olarak adil güven ile.
• Statik iş anahtarlarına sahip arama tabloları .
  İşletmenize dışarıdan sabitlenmiş
  ve herhangi bir pratik amaç için hiç değişme şansı sıfır olan benzersiz bir işletme anahtarına sahip arama tablonuz varsa
  , işletme anahtarını doğrudan kullanmak
  işleri daha kolaylaştırabilir. Bir örnek, eyalet veya il
  kodlarının bir listesi veya ANSI standart numaralarının bir listesi olabilir.
• Birden fazla ve bağımsız kaynaktan elde edilen verileri içeren tablolar . Sisteminizde tek bir masaya birlikte bağlanması gereken birçok veri kaynağı varsa, örneğin merkez ofiste, o zaman bazen kaynak sistem anahtar değerini içeren bir bileşik anahtar ve kaynak sistemin ne olduğunu gösteren bir kod gerekir.

Eski sadık monoton olarak artan tam sayı vekil anahtarının ideal olmadığı bazı durumlar da vardır. Alfanümerik suretler olan tuşlara sahip olabilirsiniz. Bunlar şunları içerebilir:

• Birden fazla ve bağımsız kaynaktan gelen verileri birleştirmeniz gereken durumlar. Anahtar çarpışmalarını önlemek için, IDENTITY tuşları yerine GUID'ler kullanabilirsiniz.
• Sayısal olmayan anahtar gösterimleri kullanmaya zorlandığınız durumlar. Diyelim ki bir plakalı veritabanınız var. Anahtarınız, saf sayı yerine alfanümerik değer olabilir.
• Bazı dış gereksinimlerin sizi sıkıştırma değerinize sıkıştırma uygulamasına zorladığı durumlar. Bir int32 için 10 hane kullanmak yerine altı temel 36 hane kullanabilirsiniz.

Neden çoğu zaman evet? Bu sorunun en temel cevabı, herhangi bir masadaki birincil anahtar değerini değiştirmeniz gerektiğinde saf cehennem olduğudur. Yana neredeyse her şey, bir kullanıcı görebilirsiniz veya dokunmatik pekala bir noktada bir güncelleme tabi saf cehennem davet ediyor görünür bir anahtar değeri kullanıyor. Bir taşıyıcı anahtar kullanmak, bu tuzağa düşmenizi önler.

Bunu söyledikten sonra, YAGNI'nin bu konsepti uygulamasında yer olduğunu unutmayın. Birisi çalışan masanızdaki erkek cinsiyet sembolünün M'den X'e veya aptalca bir şeye değişmesi gerektiğine karar vermesi durumunda, şemanızın her köşesine ve huysuzluğuna KİMLİK anahtarları içeren kod tabloları zorlamanıza gerek yoktur.

Yok hayır.

En azından yabancı anahtarlar için tek alanlı anahtarların bileşik anahtarlardan daha düşük olduğu durumlarda kesinlikle durumlar olduğunu söyleyebilirim . Bu, eğer tercih ederseniz, aynı zamanda tek alanlı bir vekil anahtarına sahip olmamanız gerektiği anlamına gelir, ancak kişisel olarak, birincil anahtar olarak adlandırılacak yabancı anahtarın hedefi olarak en sık kullanılan anahtarı kişisel olarak tercih ederim.

Amacımı aşağıdaki örneklerde göstermeye çalışacağım, ki burada:

• brand araba markasıdır, örneğin Ford, Toyota vb.
• dealer bir markaya bağlı fiziki bir bayiliktir (örneğin, yalnızca Fords satan bir Ford bayii)
• model araba tipidir; örneğin, Ford Focus, Ford Fiesta vb.
• stock Bayilik için geçerli ön ödemeli araç sayısı

Aşağıdaki gibi dealerve için tek alanlı bir vekil anahtar oluşturursak model:

create table brand( brand_id integer primary key );

create table dealer( dealer_id integer primary key, 
                     brand_id integer references brand )

create table model( model_id integer primary key, 
                    brand_id integer references brand )

create table stock( model_id integer references model, 
                    dealer_id integer references dealer, 
                    quantity integer,
                      primary key(model_id, dealer_id) )

o zaman stockbir Ford'u dealerbir "Toyota" modeline bağlayan bir sıra eklemek mümkündür . Ekleme brand_id references brandiçin stocktek sorun daha da kötüleştirir. Öte yandan, yabancı anahtarı birincil anahtarın bir parçası olarak tutarsak:

create table brand( brand_id integer primary key );

create table dealer( brand_id integer references brand, 
                     dealer_id integer, 
                       primary key(brand_id, dealer_id) )

create table model( brand_id integer references brand, 
                    model_id integer, 
                      primary key(brand_id, model_id) )

create table stock( brand_id integer, 
                    model_id integer, 
                    dealer_id integer, 
                    quantity integer,
                      primary key(brand_id, model_id, dealer_id),
                      foreign key(brand_id, model_id) references model,
                      foreign key(brand_id, dealer_id) references dealer )

Şimdi "Ford" bayilerinin yalnızca "Ford" otomobillerini stoklayabilmesi kuralı, model tarafından doğal olarak uygulanmaktadır.

'Bileşik tuşlar' örneğinde, dealer_idtercihe göre benzersiz olabilir veya olmayabilir. Benzersiz olması gerekmez (yani alternatif bir anahtar), ancak bunu (çok az bir depolama alanı) yaparak çok az şey kaybedilir ve çok kullanışlı olabilir;

create table dealer( brand_id integer references brand, 
                     dealer_id serial unique, 
                       primary key(brand_id, dealer_id) )

"değişir"

Evet: Vekil IDENTITY / AUTONUMBER alanları, doğal anahtar geniş ve sayısal olmadığında iyidir. Not: Bu, varsayılan olarak SQL Server ve Sybase vb'de meydana gelen "PK" ve kümelenmiş indeks konflasyonunu varsayar.

No: 2 üst anahtar yeterli olduğunda birçok / birçok tablo. Veya doğal anahtar kısa ve sabit olduğunda, örneğin para birimi kodu

Tabii ki, bir beyin fırtınası ORM (okuma: (n) Hazırda Bekletme) bu kuralları koyabilir ...

Düzenleme: tekrar soru okuma

2 vekil ebeveyn anahtarına sahip olan çok / çok sayıda tabloda, çok sayıda sütun PK olacaktır.
Ancak, başka bir vekil sütuna ihtiyaç duymaz.

Bir tablonun bir vekil (IDENTITY etc) anahtarı varsa, birden çok sütun olması gerekmez.

Vekili içeren bir süper anahtara sahip olabilirsiniz ancak bu diğer kuralları (ör. Alt tipler ) uygulamaktır.