İşte yine başlıyoruz, eski argüman hala ortaya çıkıyor ...

Bir işletme anahtarı birincil anahtar olarak daha iyi olsaydı, yoksa işletme anahtarı alanında benzersiz bir kısıtlamaya sahip bir yedek kimliğimiz (yani bir SQL Server kimliği) olmasını ister miydik?

Lütfen teorinizi destekleyecek örnekler veya kanıtlar sağlayın.

Her ikisi de. Pastanı al ve ye.

Birincil anahtarla ilgili özel bir şey olmadığını unutmayın, ancak bu şekilde etiketlenmesi gerekir. NOT NULL UNIQUE kısıtlamasından başka bir şey değildir ve bir tablonun birden fazla değeri olabilir.

Yedek bir anahtar kullanırsanız, iş kurallarına göre benzersizliği sağlamak için yine de bir iş anahtarı istersiniz.

Yedek anahtarları kullanmanın sadece birkaç nedeni:

1. Kararlılık : Bir işletme veya doğal ihtiyaç nedeniyle bir anahtarın değiştirilmesi ilgili tabloları olumsuz etkileyecektir. Vekil anahtarlar nadiren, eğer varsa, değere bağlı bir anlam olmadığı için değiştirilmelidir.

2. Sözleşme : PK'ları için çeşitli adlara sahip tablolara nasıl katılacağınızı düşünmek yerine standartlaştırılmış Birincil Anahtar sütun adlandırma kuralına sahip olmanızı sağlar.

3. Hız : PK değerine ve türüne bağlı olarak, bir tamsayının bir yedek anahtarı daha küçük, dizine eklenmesi ve aranması daha hızlı olabilir.

Görünüşe göre hiç kimse vekil olmayan anahtarları ("doğal" demekten çekinmeyin) hiçbir şey söylemedi. İşte gidiyor ...

Yedek anahtarların bir dezavantajı , anlamsız olmalarıdır (bazıları tarafından bir avantaj olarak belirtilir, ancak ...). Bu bazen sorgunuzda gerçekten gerekli olduğundan çok daha fazla tabloya katılmaya zorlar. Karşılaştırmak:

select sum(t.hours)
from timesheets t
where t.dept_code = 'HR'
and t.status = 'VALID'
and t.project_code = 'MYPROJECT'
and t.task = 'BUILD';

karşısında:

select sum(t.hours)
from timesheets t
     join departents d on d.dept_id = t.dept_id
     join timesheet_statuses s on s.status_id = t.status_id
     join projects p on p.project_id = t.project_id
     join tasks k on k.task_id = t.task_id
where d.dept_code = 'HR'
and s.status = 'VALID'
and p.project_code = 'MYPROJECT'
and k.task_code = 'BUILD';

Birisi aşağıdakilerin ciddi bir şekilde düşünmediği sürece iyi bir fikir mi ?:

select sum(t.hours)
from timesheets t
where t.dept_id = 34394
and t.status_id = 89    
and t.project_id = 1253
and t.task_id = 77;

"Ama" birisi diyecektir, "MYPROJECT veya VALID veya HR kodu değiştiğinde ne olur?" Hangi cevabım şöyle olacaktır: "Neden olur ihtiyaç değiştirmek için?" Bunlar, bazı dış organların bundan böyle 'VALID'in' İYİ 'olarak yeniden kodlanması gerektiğine karar vermesi anlamında "doğal" anahtarlar değildir. "Doğal" tuşların sadece küçük bir yüzdesi bu kategoriye girer - SSN ve Posta kodu her zamanki örneklerdir. Kişi, Adres gibi tablolar için kesinlikle anlamsız bir sayısal anahtar kullanırdım - ama her şey için değil , bu yüzden çoğu insan burada savunuyor gibi görünüyor.

Ayrıca bakınız: başka bir soruya cevabım

Yedek anahtarın ASLA değiştirmek için bir nedeni yoktur. Doğal anahtarlar için aynı şeyi söyleyemem. Soyadları, e-postalar, ISBN kopyaları - hepsi bir gün değişebilir.

Yedek anahtarlar (genellikle tamsayılar), tablo ilişkilerinizi daha hızlı ve depolama ve güncelleme hızında daha ekonomik hale getirmenin katma değerine sahiptir (daha da iyisi, yedek anahtarları kullanırken, iş anahtar alanlarının aksine, yabancı anahtarların güncellenmesine gerek yoktur, o zaman zaman değişir).

Tablonun birincil anahtarı, esas olarak birleştirme amaçları için satırı benzersiz bir şekilde tanımlamak için kullanılmalıdır. Bir Kişiler tablosu düşünün: isimler değişebilir ve benzersiz oldukları garanti edilmez.

Düşünen Şirketler: Merkia'daki diğer şirketlerle iş yapan mutlu bir Merkin şirketidir. Şirket adını birincil anahtar olarak kullanmayacak kadar zekisiniz, bu nedenle Merkia hükümetinin benzersiz şirket kimliğini 10 alfasayısal karakterden tamamen kullanıyorsunuz. Sonra Merkia, şirket kimliklerini değiştirdi çünkü iyi bir fikir olacağını düşündüler. Tamam, db motorunuzun basamaklı güncellemeler özelliğini kullanıyorsunuz, ilk etapta sizi içermemesi gereken bir değişiklik için. Daha sonra işiniz genişler ve şimdi Freedonya'daki bir şirketle çalışıyorsunuz. Freedonya şirket kimliği 16 karaktere kadar. Birincil anahtarı (ayrıca yabancı anahtarlarda) bir Ülke alanı ekleyerek, şirket kimliği birincil anahtarını (Siparişler, Sorunlar, Para Transferleri vb. Yabancı anahtar alanları) genişletmeniz gerekir. Ah! Freedonya'da iç savaş, o ' üç ülkeye ayrılmıştır. İş arkadaşınızın ülke adı yenisiyle değiştirilmelidir; kurtarma güncellemeleri basamaklı. BTW, birincil anahtarınız nedir? (Ülke, Şirket Kimliği) veya (Şirket Kimliği, Ülke)? İkincisi katılmaya yardımcı olur, birincisi başka bir dizinden kaçınır (veya Siparişlerinizin ülkeye göre gruplanmasını istiyorsanız belki de çok sayıda).

Tüm bunlar kanıt değildir, ancak birleştirme işlemi de dahil olmak üzere tüm kullanımlar için bir satırı benzersiz bir şekilde tanımlayan bir yedek anahtarın bir iş anahtarına tercih edildiğinin bir göstergesidir.

Genel olarak yedek anahtarlardan nefret ediyorum. Sadece kaliteli doğal anahtar olmadığında kullanılmalıdır. Bunu düşündüğünüzde, tablonuza anlamsız veri eklemenin işleri daha iyi hale getirebileceğini düşünmek oldukça saçmadır.

İşte nedenlerim:

1. Doğal anahtarlar kullanıldığında, tablolar en sık aranacakları şekilde kümelenir ve böylece sorguları daha hızlı hale getirir.

2. Yedek anahtarları kullanırken, mantıksal anahtar sütunlarına benzersiz dizinler eklemeniz gerekir. Yine de mantıksal yinelenen verileri önlemeniz gerekir. Örneğin, pk bir yedek kimlik sütunu olmasına rağmen, aynı adı taşıyan iki Kuruluşa Organizasyon tablonuzda izin veremezsiniz.

3. Yedek anahtarlar birincil anahtar olarak kullanıldığında, doğal birincil anahtarların ne olduğu çok daha az açıktır. Geliştirirken hangi sütun kümesinin tabloyu benzersiz kıldığını bilmek istersiniz.

4. Bir-çok ilişki zincirinde, mantıksal anahtar zincirleri. Örneğin, Örgütlerin çok sayıda Hesabı ve Hesapların çok sayıda Faturaları vardır. Organizasyonun mantıksal anahtarı OrgName'dir. Hesapların mantıksal anahtarı OrgName, AccountID'dir. Faturanın mantıksal anahtarı OrgName, AccountID, InvoiceNumber'dır.

   Yedek anahtarlar kullanıldığında, anahtar zincirler yalnızca ana ebeveyne yabancı bir anahtar kullanılarak kesilir. Örneğin, Fatura tablosunda bir OrgName sütunu yoktur. Yalnızca AccountID için bir sütunu vardır. Belirli bir kuruluşun faturalarını aramak istiyorsanız Kuruluş, Hesap ve Fatura tablolarına katılmanız gerekir. Mantıksal anahtarlar kullanırsanız, doğrudan Kuruluş tablosunu sorgulayabilirsiniz.

5. Arama tablolarının yedek anahtar değerlerinin depolanması tabloların anlamsız tamsayılarla doldurulmasına neden olur. Verileri görüntülemek için, tüm arama tablolarına katılan karmaşık görünümler oluşturulmalıdır. Arama tablosu, bir sütun için kabul edilebilir değerler kümesini tutmak içindir. Bunun yerine bir tamsayı vekil anahtarı saklanarak kodlanmamalıdır. Normalleştirme kurallarında, değerin kendisi yerine bir tamsayı saklamanız gerektiğini öneren hiçbir şey yoktur.

6. Üç farklı veritabanı kitabım var. Bunlardan hiçbiri yedek anahtarlar kullanarak göstermez.

Bu sonsuz savaşta deneyimlerimi sizlerle paylaşmak istiyorum: Doğal ve yedek anahtar ikilemi üzerindeki D. Ben düşünüyorum hem vekil tuşları (yapay otomatik oluşturulan olanlar) ve (domain anlam sütun (s oluşan)) doğal tuşları var artıları ve eksileri . Durumunuza bağlı olarak, bir yöntem veya diğerini seçmek daha uygun olabilir.

Birçok insan vekil olarak neredeyse mükemmel çözüm ve doğal anahtarlar vekil anahtarlar sunarken, diğer bakış açısının argümanlarına odaklanacağım:

Yedek anahtarların dezavantajları

Yedek anahtarlar:

1. Performans sorunlarının kaynağı:
   • Genellikle otomatik olarak artırılan sütunlar kullanılarak uygulanır:
     • Her yeni bir kimlik almak istediğinizde veritabanına gidiş-dönüş (bunun önbellek veya [seq] hilo algoritmaları kullanılarak geliştirilebileceğini biliyorum, ancak yine de bu yöntemlerin kendi dezavantajları var).
     • Bir gün verilerinizi bir şemadan diğerine taşımanız gerekiyorsa (En azından şirketimde oldukça düzenli olur) o zaman Kimlik çarpışma problemleriyle karşılaşabilirsiniz. Ve Evet, UUID'leri kullanabileceğinizi biliyorum, ancak bu süreler 32 onaltılık basamak gerektirir! (Veritabanı boyutunu önemsiyorsanız, bu bir sorun olabilir).
     • Tüm yedek anahtarlarınız için bir sıra kullanıyorsanız, o zaman - kesin olarak - veritabanınızda çekişme ile sonuçlanırsınız.
2. Yüzüstü hata. Bir dizinin bir max_value sınırı vardır; bu nedenle - geliştirici olarak - aşağıdaki noktalara dikkat etmeniz gerekir:
   • Sekansınızı döngüye sokmanız gerekir (maksimum değere ulaşıldığında 1,2, ... 'e geri döner).
   • Sekansı verilerinizin sıralaması (zaman içinde) olarak kullanıyorsanız, döngü durumunu ele almanız gerekir (Id 1 ile sütun, Id max-değeri - 1 ile satırdan daha yeni olabilir).
   • Kodunuzun (ve dahili bir kimlik olması gerektiği gibi olmaması gereken istemci arayüzlerinizin) sıra değerlerinizi depolamak için kullandığınız 32b / 64b tamsayılarını desteklediğinden emin olun.
3. Çoğaltılmamış verileri garanti etmezler. Her zaman aynı sütun değerlerine sahip ancak farklı bir oluşturulan değere sahip 2 satırınız olabilir. Benim için bu bir görüş veritabanı tasarımı açısından vekil anahtarların sorunu.
4. Wikipedia'da daha fazlası ...

Doğal Anahtarlardaki Mitler

1. Kompozit anahtarlar, yedek anahtarlardan daha az verimsizdir. Hayır! Kullanılan veritabanı motoruna bağlıdır:
   • torpil
   • MySQL
2. Doğal anahtarlar gerçek hayatta yoktur. Üzgünüm ama varlar! Örneğin, havacılık endüstrisinde, belirli bir tarifeli uçuş (havayolu, kalkış tarihi, uçuş numarası, operasyonelSuffix) için aşağıdaki grup her zaman benzersiz olacaktır . Daha genel olarak, bir dizi iş verisinin belirli bir standart tarafından benzersiz olduğu garanti edildiğinde bu veri seti [iyi] bir doğal anahtar adayıdır.
3. Doğal anahtarlar çocuk masalarının "şemasını kirletir". Benim için bu gerçek bir problemden daha fazla bir duygu. Her biri 2 baytlık bir 4 anahtar birincil anahtarına sahip olmak, 11 baytlık tek bir sütundan daha verimli olabilir. Ayrıca, 4 sütun, üst tabloya katılmadan doğrudan alt tabloyu sorgulamak için (nerede yan tümcesinde 4 sütun kullanarak) kullanılabilir.

Sonuç

Alakalı olduğunda doğal anahtarlar kullanın ve bunları kullanmak daha iyi olduğunda yedek anahtarlar kullanın.

Umarım bu birisine yardımcı olmuştur!

Her zaman ticari anlamı olmayan bir anahtar kullanın. Bu sadece iyi bir uygulama.

EDIT: Çevrimiçi bir bağlantı bulmaya çalışıyordum, ama yapamadım. Bununla birlikte, 'Kurumsal Mimari Desenleri' [Fowler] 'de, neden bir anahtar olmaktan başka bir anlamı olmayan bir anahtardan başka bir şey kullanmamanız gerektiği konusunda iyi bir açıklaması vardır. Sadece bir işi ve sadece bir işi olması gerektiği gerçeğine dayanır.

Veri sınıflarınızı işlemek / oluşturmak için bir ORM aracı kullanmayı planlıyorsanız yedek anahtarlar oldukça kullanışlıdır. Bazı daha gelişmiş eşleyicilerle birlikte birleşik anahtarlar kullanabilirsiniz (read: hibernate), kodunuza biraz karmaşıklık katar.

(Tabii ki, veritabanı meraklıları bir yedek anahtar kavramının bile iğrenç olduğunu iddia edecektir.)

Ben uygun olduğunda vekil anahtarlar için uids kullanma hayranıyım. Onlarla kazanılan en büyük kazanç, anahtarı önceden bilmenizdir, örneğin, önceden tanımlanmış ve benzersiz olduğu garanti edilen kimliğe sahip bir sınıf örneği oluşturabilirsiniz, örneğin, bir tamsayı anahtarı ile varsayılan olarak 0 veya - 1 ve kaydettiğinizde / güncellediğinizde uygun bir değere güncelleyin.

UID'lerin arama ve katılma hızı açısından cezaları vardır, ancak bu, istenen olup olmadıklarına göre söz konusu uygulamaya bağlıdır.

Bir yedek anahtar kullanmak bence daha iyidir çünkü değişme şansı sıfırdır. Doğal bir anahtar olarak kullanabileceğiniz hemen hemen her şey değişebilir (sorumluluk reddi: her zaman doğru değil, ancak yaygın olarak).

Bir örnek araba DB'si olabilir - ilk bakışta, plakanın anahtar olarak kullanılabileceğini düşünebilirsiniz. Ancak bunlar değiştirilebilir, böylece bu kötü bir fikir olabilir. Birisi size plakalarını neden parlak yeni kişiselleştirilmiş olanına değiştiremediğini bilmek isteyen geldiğinde, uygulamayı bıraktıktan sonra bunu öğrenmek istemezsiniz .

Her zaman tek bir sütun kullanın, mümkünse anahtarı yedekleyin. Bu, ekleri / güncellemeleri / silmelerin yanı sıra eklemeleri çok daha temiz hale getirir, çünkü yalnızca kaydı korumak için tek bir bilgiyi izlemekle sorumlusunuz.

Ardından, gerektiğinde, işletme anahtarlarınızı benzersiz bir karşıtlık veya dizin olarak istifleyin. Bu, veri bütünlüğünü koruyacaktır.

İş mantığı / doğal anahtarlar değişebilir, ancak tablonun fiziksel anahtarı ASLA değişmemelidir.

Bir datawarehouse senaryosunda, vekil anahtar yolunu izlemenin daha iyi olduğuna inanıyorum. İki sebep:

• Kaynak sistemden bağımsızsınız ve buradaki değişiklikler - veri türü değişikliği gibi - sizi etkilemez.
• Yedek anahtarlarınız için yalnızca tamsayı veri türlerini kullanacağınız için DW'nizin daha az fiziksel alana ihtiyacı olacaktır. Ayrıca dizinleriniz daha iyi çalışır.

Yedek anahtarlar, işletme bilgileri değiştiğinde veya özdeş olduğunda yararlı olabilir. Sonuçta, işletme adlarının ülke genelinde benzersiz olması gerekmez. Biri Kansas'ta ve diğeri Michigan'da olmak üzere Smith Electronics adlı iki işletme ile uğraştığınızı varsayalım. Onları adrese göre ayırt edebilirsiniz, ancak bu değişecektir. Devlet bile değişebilir; Kansas City, Kansas'tan Smith Electronics nehir boyunca Kansas City, Missouri'ye taşınırsa? Bu işletmeleri doğal anahtar bilgilerden ayrı tutmanın belirgin bir yolu yoktur, bu nedenle yedek anahtar çok yararlıdır.

Yedek anahtarı bir ISBN numarası gibi düşünün. Genellikle, bir kitabı başlığa ve yazara göre tanımlarsınız. Ancak, HP Willmott tarafından "Pearl Harbor" başlıklı iki kitabım var ve bunlar sadece farklı sürümler değil, kesinlikle farklı kitaplar. Böyle bir durumda, kitapların görünüşüne veya daha öncekine karşı kitaplara atıfta bulunabilirim, ancak geri çekilmem için ISBN de var.

Bir hatırlatma olarak, kümelenmiş indeksleri rasgele vekil anahtarlara yerleştirmek iyi bir uygulama değildir, yani SQL Server'ın bu verileri fiziksel olarak sıralayama yeteneği olmadığı için XY8D7-DFD8S'yi okuyan GUID'ler. Bunun yerine, bu tablolara benzersiz indeksler yerleştirmelisiniz, ancak ana tablo işlemleri için SQL profiler çalıştırmak ve daha sonra bu verileri Veritabanı Altyapısı Ayarlama Danışmanına yerleştirmek de yararlı olabilir.

Bkz. Konu @ http://social.msdn.microsoft.com/Forums/en-us/sqlgetstarted/thread/27bd9c77-ec31-44f1-ab7f-bd2cb13129be

Durum 1: Tablonuz,50'den az türü (araya ekleme) içerenbir arama tablosu

Kullanım iş / doğal tuşları . Örneğin:

Table: JOB with 50 inserts
CODE (primary key)       NAME               DESCRIPTION
PRG                      PROGRAMMER         A programmer is writing code
MNG                      MANAGER            A manager is doing whatever
CLN                      CLEANER            A cleaner cleans
...............
joined with
Table: PEOPLE with 100000 inserts

foreign key JOBCODE in table PEOPLE
looks at
primary key CODE in table JOB

Durum 2: Tablonuz binlerce ek içeren bir tablodur

Kullanım vekil / autoincrement tuşları . Örneğin:

Table: ASSIGNMENT with 1000000 inserts
joined with
Table: PEOPLE with 100000 inserts

foreign key PEOPLEID in table ASSIGNMENT
looks at
primary key ID in table PEOPLE (autoincrement)

İlk durumda:

• Tablo PEOPLE içindeki tüm programcıları JOB tablosu ile birleştirme kullanmadan seçebilirsiniz, ancak yalnızca "SELECT * FOP PEOPLE WOBE WOBE = 'PRG" "

İkinci durumda:

• Birincil anahtarınız bir tamsayı olduğu için veritabanı sorgularınız daha hızlı
• Bir sonraki benzersiz anahtarı bulmakla uğraşmanıza gerek yok çünkü veritabanının kendisi size bir sonraki otomatik baskıyı sağlıyor.

Bu, bir yedek anahtarın hemen hemen her zaman mantıklı olduğu durumlardan biridir . Veritabanı için en iyi olanı veya nesne modeliniz için en iyisini seçebileceğiniz durumlar vardır, ancak her iki durumda da anlamsız bir anahtar veya GUID kullanmak daha iyi bir fikirdir. İndekslemeyi daha kolay ve daha hızlı hale getirir ve nesneniz için değişmeyen bir kimliktir.

Atlar için kurslar. Önyargımı belirtmek için; Öncelikle geliştiriciyim, bu yüzden esas olarak kullanıcılara çalışan bir uygulama sunmakla ilgileniyorum.

Doğal anahtarlı sistemler üzerinde çalıştım ve değer değişikliklerinin dalgalanacağından emin olmak için çok zaman harcadım.

Yalnızca yedek anahtarları olan sistemler üzerinde çalıştım ve tek dezavantajı, bölümleme için denormalize veri eksikliği oldu.

Birlikte çalıştığım çoğu geleneksel PL / SQL geliştiricisi, katılım başına tablo sayısı nedeniyle yedek anahtarları beğenmedi, ancak test ve üretim veritabanlarımız asla ter atmadı; fazladan birleşimler uygulama performansını etkilemedi. "Xa = Yb'de X iç birleşimi Y" gibi yan tümceleri desteklemeyen veritabanı lehçeleri veya bu sözdizimini kullanmayan geliştiricilerle, yedek anahtarlar için ek birleşimler sorguların okunmasını zorlaştırır ve kontrol edin: @Tony Andrews gönderisine bakın. Ancak bir ORM veya başka bir SQL oluşturma çerçevesi kullanıyorsanız bunu fark etmeyeceksiniz. Dokunarak yazma da hafifletir.

Belki bu konuyla tamamen ilgili değil, yedek anahtarlarla uğraştığım bir baş ağrısı. Oracle önceden teslim edilen analitik, depodaki tüm boyut tablolarında otomatik olarak oluşturulan SK'ları oluşturur ve bunları gerçekler üzerine depolar. Bu nedenle, yeni sütunlar eklendikçe veya boyuttaki tüm öğeler için doldurulmaları gerektiğinde (boyutlar) yeniden yüklenmeleri gerektiğinde, güncelleme sırasında atanan SK'ler SK'ları gerçeğe depolanan orijinal değerlerle senkronize etmez, zorlar ona katılan tüm olgu tablolarının tam olarak yeniden yüklenmesi. SK anlamsız bir sayı olsa bile, orijinal / eski kayıtlar için değişememesinin bir yolu olacağını tercih ederim. Birçoğunun bildiği gibi, kutunun dışında nadiren bir kuruluşun ihtiyaçlarına hizmet eder ve sürekli olarak özelleştirmemiz gerekir. Şimdi depomuzda 3 yıl değerinde veri var, ve Oracle Financial sistemlerinden tam yeniden yükleme çok büyük. Yani benim durumumda, veri girişinden üretilmiyorlar, ancak performans raporlamasına yardımcı olmak için bir depoya ekleniyorlar. Anlıyorum, ama bizimki değişiyor ve bu bir kabus.

Zaman içinde veritabanı durumunda, vekil ve doğal anahtarların kombinasyonuna sahip olmak en iyisidir. örneğin bir kulübe üye bilgilerini izlemeniz gerekir. Bir üyenin bazı özellikleri hiçbir zaman değişmez. Örneğin Doğum Tarihi ancak adı değişebilir. Bu nedenle, member_id yedek anahtarıyla bir Üye tablosu oluşturun ve DOB için bir sütununuz olsun. Kişi adı adlı başka bir tablo oluşturun ve member_id, member_fname, member_lname, date_updated için sütunlara sahip olun. Bu tabloda doğal anahtar member_id + date_updated olacaktır.