Bir anahtar neden açıklanmalıdır?

15

Veritabanları konusunda çok yeniyim, bu yüzden bu cahil gelebilir, ancak bir anahtarın neden bir tabloda açık hale getirilmesi gerektiğini merak ediyorum. Bu öncelikle kullanıcıya verilen sütun değerinin (umarım) her satırda benzersiz olduğunu garanti etmek mi? Teklikten bahsedilmese bile hala orada olmalıdır.

primary-key unique-constraint

— dsaxton
kaynak

UNIQUE anahtarınız varsa, neden PRIMARY anahtarına sahip olmaktan rahatsız oluyorsunuz?

— Vérace

1

Sadece neden ilan edildi? Çok yararlı görünüyor, ancak gerçekten çalışan bir veritabanına sahip olmak gerekli mi?

— dsaxton

1

Veritabanınızın çalışması için gerekli değildir, ancak verilerinizin "çalışması" için, yani tutarlı olması için gereklidir, çünkü tam olarak veritabanı sunucunuza bilgileri tutarlı tutmasını söylersiniz.

— Andriy M

Veritabanı biliyorsa belirli bir alanın bir anahtar olduğunu , bir yan etki, anahtarı içeren satırı tablolardaki tüm satırlara bakması gerekenden çok daha hızlı bulmanıza yardımcı olabilmesidir. Dizinler, veritabanlarının neden yararlı olduğunun çok önemli bir parçasıdır.

— Thorbjørn Ravn Andersen

32

Açıkçası CONSTRAINTbir veritabanındaki bu veritabanına erişen uygulamalar tarafından uygulanmasını öneriyoruz ?

Bunun kötü (kötü, kötü ...) bir fikir olmasının birçok nedeni vardır .

1) Eğer bir "kendi rulo" kısıtlaması "motoru (örneğin uygulama kodunuzda) oluşturuyorsanız, Oracle / SQL Server / MySQL / PostgreSQL / <. yıl yazma. CONSTRAINT kodları tam anlamıyla milyonlarca son kullanıcı tarafından test edildi .

2) Size ve ekibinize gereken tüm saygıyla, birkaç yıl içinde bile doğru elde edemezsiniz - buradan yalnızca MySQL kodu 40 Milyon dolara mal olur. Ve MySQL yukarıdaki 3 sunucunun en ucuzudur ve CHECK CONSTRAINT'leri bile uygulamamaktadır. Açıkçası, RI'yi (Referans Bütünlüğü) tamamen doğru yapmak zordur.

Oracle forumlarını sık sık yapıyordum ve bazı fakir yöneticilerin / programcıların, daha önce işini yapan dahi, önerisini yapmanın "parlak" fikrine sahip olduğu bir projeye ne kadar sürdüğünü söyleyemem. .

Jonathan Lewis ( Oracle optimiser'ın temelleri üzerine 550 sayfalık bir kitap yazdı ) hayır veriyor. Tasarım Felaketlerinden 2'si başka bir kitapta (" Meşe Masasının Masalları ") " - Meşe Masalı bir Oracle uzmanları grubudur)

Oracle'ın kısıt kontrolü yeteneklerinden yararlanmak yerine veri bütünlüğünü uygulama düzeyinde kontrol edeceğiz.

3) Bir mucize olsa bile düzgün RI uygulayabilir, bunu yapmak zorunda olacak tamamen veriler önemlidir ve eğer o zaman yeni uygulamalar olacak - o dokunuşlar veritabanında her uygulama için bunu tekrar tekrar reimplement. Bunu bir paradigma olarak seçmek, sizin ve diğer programcılarınızın (destek personeli ve satıştan bahsetmemek) sürekli bir yangınla mücadele ve sefalet yaşamına yol açacaktır.

Verileri uygulama düzeylerinde uygulamanın CONSTRAINT'lerin neden burada , burada ve burada edinebilirsiniz .

Sorunuzu özellikle cevaplamak için:

Sadece neden ilan edildi? Çok yararlı görünüyor, ancak aslında çalışan bir veritabanına sahip olmak gerekli mi?

Nedeni KEYler (ya PRIMARY, FOREIGN, UNIQUEya da sadece sıradan INDEXöyle ise es) ilan edilir, yani kesinlikle değil o işlev için bir veri tabanı onlara sahip olmak için gerekli olduğunu, kesinlikle onlara işleve bunun için beyan edilmesi için gerekli iyi .

— Verace
kaynak

1

Cevabınız için teşekkürler. Muhtemelen tam olarak anlamak için daha fazla şey öğrenmem gerekecek. (Aslında bir takıma ait değilim, sadece meraktan çıkmış veri tabanlarını öğreniyorum.)

— dsaxton

2

Birkaç kitap okuyun (Date, Garcia-Molina ...) ve belirli sorularınız varsa bize geri dönün (aşırı geniş sorular burada konu dışı olarak kabul edilir). ps Foruma hoş geldiniz :-)

— Vérace

Asla, asla veritabanına herhangi bir kısıtlama koymamanızı öneririm (Her zaman birincil anahtar ve yabancı anahtarları en az düzeyde olmalıdır), tüm uygulamaların paylaşılan bir hizmetten (hizmet odaklı mimari) tüketmesini sağlayarak # 3'ü önleyebilirsiniz ). (Veritabanında ihtiyacınız olan her son bütünlük denetimini yapmak da kabus alabileceğinden, muhtemelen birden fazla tüketici için düşünmeniz gereken bir şeydir. Her zaman tetikleyicileri tablolar ve satırlar arasında kontroller her zaman tetikler.)

— jpmc26

10

Veritabanında bir anahtar oluşturduğunuzda DBMS altyapısı, anahtar öznitelikleri üzerinde benzersiz bir kısıtlama uygular. Bu, en az üç ilgili amaca hizmet eder:

Veri bütünlüğü: Anahtar niteliklere yinelenen veriler girilemez. Bu nedenle, tuşlara herhangi bir bağımlılık garanti edilir.
Kimlik: Kullanıcılar verileri doğru bir şekilde tanımlamak ve güncellemek için anahtarlara güvenebilir.
Optimizasyon: DBMS sorgu optimize edici tarafından hangi özelliklerin benzersiz olduğu hakkında bilgi (meta veriler) mevcuttur. Bu bilgiler, iyileştiricinin sorgu yürütmeyi belirli şekillerde basitleştirmesini sağlar, böylece sorgular daha hızlı yürütülür.

— nvogel
kaynak

8

Mevcut mükemmel cevaplara bir yön ekleyeceğim: Dokümantasyon.Genellikle bir varlığı tanımlamak için ne tür anahtarlar kullanabileceğinizi görmek önemlidir. Benzersiz sütunların herhangi bir kombinasyonu bir aday anahtardır.

Birincil anahtar pratikte özellikle yararlı bir kavram olma eğilimindedir.

Bir anahtarı uygulayıp uygulamadığınız (muhtemelen yapmalısınız) belgeler kendi başına değerlidir.

— boot4life
kaynak

1

Veritabanı diyagramları! Aşina olmadığım yazılım hakkında anlamlı bir şey söylemem istendiğinde her zaman yaptığım ilk şey, ilişkisel bir veritabanı kullanıp kullanmadığını görmek ve eğer yaparsa, bir veritabanı diyagramı oluşturmaya çalışmaktır. Bu bana uygulamanın çalıştığı bilgiler hakkında mükemmel bir fikir verecektir. Ne yazık ki, gördüğüm veritabanlarının% 90'ı yabancı anahtar bildirmiyor, bu yüzden diyagramlar sadece tablo kümeleridir. Örtülü uygulama düzeyinde yabancı anahtarları çıkarmak , tahmin ve ince ayar gerektirir.

— reinierpost

1

@reinierpost Tamamen katılıyorum. Veriler, belgelenmesi ve temiz tutulması en değerli nesnedir, çünkü sonsuza kadar devam eder. Kod değişebilir; daha geçici olma eğilimindedir.

— boot4life

@reinierpost - Büyük bir Avrupa ülkesinin tüm demiryolu altyapısı için yazılım tedarik eden bir şirkete danıştık (büyük - milyarlarca widget'ı düşünün) ve dedim ki, "Hımm, sadece FOREIGN KEYbir "sistemi hissetmek". Benim sorgu zip döndü !!! SQL'imin yanlış olması gerektiğinden eminim, bunu kıdemli programcılardan birine anlattım. İle gurur "Tüm aramalar üzerinde olduğu için sistemin herhangi FKS yoktu ki (o yeni doğmuş oğlunu takdim sanki) (az) diye açıkladı PRIMARY KEY(ilgisiz) - s". <Doh ...> a la Homer Simpson!

— Vérace

5

Bazı uygulama içi kodlar yerine CONSTRAINT'leri kullanmanızın başka bir nedeni:

Bir geliştirici / dba, doğrudan DB'deki verileri değiştirmek için bir insert / update / delete ifadesi kullanırsa ne olur? Bu durumda, tüm güzel uygulama tabanlı referans bütünlüğünüz işe yaramaz olacaktır. Biliyorum, bazı geliştiriciler, RI ile uğraşmak zorunda kalmadan verileri doğrudan değiştirme olasılığını seviyorlar, çünkü ne yaptıklarını biliyorlar - en azından en çok (her zaman değil)

Not: Tabii ki tetikleyiciler oluşturabilirsiniz, ancak genellikle korkunç yavaştır (KISITLAMALAR ile karşılaştırıldığında).

— Thomas Franz
kaynak