Bir veritabanı tasarımında yabancı anahtarlar gerçekten gerekli mi?

Bildiğim kadarıyla, yabancı anahtarlar (FK) programcının verileri doğru şekilde işlemesine yardımcı olmak için kullanılıyor. Bir programcının bunu zaten doğru şekilde yaptığını varsayalım, o zaman gerçekten yabancı anahtar kavramına ihtiyacımız var mı?

Yabancı anahtarların başka kullanımları var mı? Burada bir şey mi kaçırıyorum?

Yabancı anahtarlar, veri düzeyinde bilgi tutarlılığının uygulanmasına yardımcı olur. Ayrıca, normalde varsayılan olarak indekslendikleri için performansı da iyileştirirler.

Yabancı anahtarlar, programcının gibi şeyleri kullanarak daha az kod yazmasına da yardımcı olabilir ON DELETE CASCADE. Bu, kullanıcıları içeren bir tablonuz ve siparişleri veya başka bir şeyi içeren bir tablonuz varsa, bir kullanıcıyı silmenin o kullanıcıyı işaret eden tüm siparişleri otomatik olarak silebileceği anlamına gelir.

Yabancı anahtarlar olmadan bir veritabanı tasarlamayı hayal edemiyorum. Onlar olmadan, sonunda bir hata yapmanız ve verilerinizin bütünlüğünü bozmanız kaçınılmazdır.

Kesinlikle gerekli değiller , ancak faydaları çok büyük.

FogBugz'un veritabanında yabancı anahtar kısıtlamalarına sahip olmadığından oldukça eminim . Fog Creek Yazılım ekibinin hiçbir zaman bir tutarsızlık yaratmayacaklarını garanti etmek için kodlarını nasıl yapılandırdığını duymak isterim .

FK kısıtlamaları olmayan bir veritabanı şeması, emniyet kemeri olmadan sürmek gibidir.

Bir gün pişman olacaksın. Tasarım temelleri ve veri bütünlüğü için bu kadar az ekstra zaman harcamamak, daha sonra baş ağrılarını gidermenin kesin bir yoludur.

Başvurunuzda bu kadar özensiz olan kodu kabul eder miydiniz? Bu, üye nesnelere doğrudan erişir ve veri yapılarını doğrudan değiştirir.

Modern dillerde bunun neden zor ve hatta kabul edilemez hale geldiğini düşünüyorsunuz ?

Evet.

1. Seni dürüst tutuyorlar
2. Yeni geliştiricileri dürüst tutarlar
3. Yapabilirsin ON DELETE CASCADE
4. Tablolar arasındaki bağlantıları kendi kendine açıklayan güzel diyagramlar oluşturmanıza yardımcı olurlar

Bir programcının bunu zaten doğru şekilde yaptığını varsayalım

Böyle bir varsayımda bulunmak bana son derece kötü bir fikir gibi görünüyor; genel olarak yazılım olağanüstü derecede hatalı.

Ve asıl mesele bu, gerçekten. Geliştiriciler işleri doğru yapamazlar, bu nedenle veritabanının kötü verilerle doldurulmamasını sağlamak İyi Bir Şeydir.

İdeal bir dünyada, doğal birleşimler sütun adlarını eşleştirmek yerine ilişkileri (örn. FK kısıtlamaları) kullanır. Bu, FK'leri daha da kullanışlı hale getirecektir.

Şahsen ben yabancı anahtarlardan yanayım çünkü tablolar arasındaki ilişkiyi resmileştiriyor. Sorunuzun, programcının referans bütünlüğünü ihlal edecek verileri sunmadığını varsaydığının farkındayım, ancak en iyi niyetlere rağmen veri referans bütünlüğünün ihlal edildiği çok fazla örnek gördüm!

Ön yabancı anahtar kısıtlamaları (diğer bir deyişle bildirim temelli referans bütünlüğü veya DRI), tetikleyicileri kullanarak bu ilişkileri uygulamak için çok zaman harcandı. İlişkiyi bildirimsel bir kısıtlama ile resmileştirebilmemiz çok güçlüdür.

@John - Diğer veritabanları yabancı anahtarlar için otomatik olarak dizin oluşturabilir, ancak SQL Server bunu yapmaz. SQL Server'da yabancı anahtar ilişkileri yalnızca kısıtlamalardır. Dizininizi yabancı anahtarlar üzerinde ayrı olarak tanımlamalısınız (bu yararlı olabilir).

Düzenleme: Eklemek isterim ki, IMO, ON DELETE veya ON UPDATE CASCADE desteği için yabancı anahtarların kullanılması mutlaka iyi bir şey değildir. Uygulamada, silindikten sonra basamaklamanın verilerin ilişkisine dayalı olarak dikkatlice değerlendirilmesi gerektiğini buldum - örneğin, bunun uygun olabileceği doğal bir ebeveyn-çocuğunuz var mı veya ilgili tablo bir dizi arama değeri mi? Basamaklı güncellemeleri kullanmak, bir tablonun birincil anahtarının değiştirilmesine izin verdiğiniz anlamına gelir. Bu durumda, bir tablonun birincil anahtarının değişmemesi gerektiği konusunda genel bir felsefi anlaşmazlığım var. Anahtarlar doğası gereği sabit olmalıdır.

Yabancı anahtar olmadan, farklı tablolardaki iki kaydın birbiriyle ilişkili olduğunu nasıl anlarsınız?

Bence bahsettiğiniz şey, alt kaydın mevcut bir ana kayıt olmadan oluşturulmasına izin verilmeyen referans bütünlüğüdür. Bunlar genellikle yabancı anahtar kısıtlamaları olarak bilinir - ancak buradaki yabancı anahtarların varlığı ile karıştırılmamalıdır. ilk sırada.

Yabancı anahtarlara sahip olmamanın bir faydası var mı? Kötü bir veritabanı kullanmadığınız sürece, FK'leri kurmak o kadar da zor değildir. Öyleyse neden onlardan kaçınma politikanız olsun? Bir sütunun diğerine başvurduğunu söyleyen bir adlandırma kuralına sahip olmak bir şeydir, veritabanının aslında bu ilişkiyi sizin için doğruladığını bilmek başka bir şeydir.

Sanırım veritabanı tarafından uygulanan yabancı anahtar kısıtlamalarından bahsediyorsunuz . Muhtemelen zaten yabancı anahtarlar kullanıyorsunuz, sadece veritabanına bundan bahsetmediniz.

Bir programcının bunu zaten doğru şekilde yaptığını varsayalım, o zaman gerçekten yabancı anahtar kavramına ihtiyacımız var mı?

Teorik olarak hayır. Ancak, hiçbir zaman hatasız bir yazılım parçası olmadı.

Uygulama kodundaki hatalar genellikle o kadar tehlikeli değildir - hatayı tanımlar ve düzeltirsiniz ve bundan sonra uygulama tekrar sorunsuz çalışır. Ancak bir hata mevcut verilerin veritabanına girmesine izin veriyorsa, o zaman ona takılıp kalırsınız! Veritabanındaki bozuk verilerden kurtarmak çok zordur.

FogBugz'daki küçük bir hatanın , veritabanına bozuk bir yabancı anahtarın yazılmasına izin verip vermediğini düşünün . Bir hata düzeltme sürümünde hatayı düzeltmek ve düzeltmeyi hızla müşterilere göndermek kolay olabilir. Ancak düzinelerce veritabanındaki bozuk veriler nasıl düzeltilmelidir? Doğru kod artık aniden bozulabilir çünkü yabancı anahtarların bütünlüğü hakkındaki varsayımlar artık geçerli değildir.

Web uygulamalarında genellikle veri tabanına konuşan yalnızca bir programınız vardır, bu nedenle hataların verileri bozabileceği tek bir yer vardır. Kurumsal bir uygulamada, aynı veritabanına konuşan birkaç bağımsız uygulama olabilir (doğrudan veritabanı kabuğuyla çalışan kişilerden bahsetmeye gerek yok). Tüm uygulamaların her zaman ve sonsuza kadar hatasız aynı varsayımları takip ettiğinden emin olmanın bir yolu yoktur.

Veritabanında kısıtlamalar kodlanmışsa, hatalarla karşılaşılabilecek en kötü şey, kullanıcıya bazı SQL kısıtlamalarının karşılanmadığı hakkında çirkin bir hata mesajı gösterilmesidir . Bu, tüm uygulamalarınızı bozacağı veya her türlü yanlış veya yanıltıcı çıktıya yol açacağı kurumsal veritabanınıza güncel verilerin girmesine izin vermek için çok tercih edilir.

Oh, ve yabancı anahtar kısıtlamaları da varsayılan olarak indekslendikleri için performansı artırır. Ben herhangi bir nedenle düşünemiyorum değil yabancı anahtar kısıtlamalarını kullanmak.

FK'ler çok önemlidir ve eBay değilseniz her zaman şemanızda bulunmalıdır .

Bence bir noktada geçerli ilişkiler sağlamaktan tek bir şey sorumlu olmalı.

Örneğin Ruby on Rails yabancı anahtarlar kullanmaz, ancak tüm ilişkilerin kendisini doğrular. Veritabanınıza yalnızca o Ruby on Rails uygulamasından erişirseniz, bu sorun değildir.

Ancak, veritabanına yazan başka müşterileriniz varsa, yabancı anahtarlar olmadan kendi doğrulamalarını gerçekleştirmeleri gerekir. Daha sonra, doğrulama kodunun büyük olasılıkla farklı olan iki kopyasına sahip olursunuz ve herhangi bir programcının bunu söylemesi büyük bir günahtır.

Bu noktada, sorumluluğu tekrar tek bir noktaya taşımanıza izin verdikleri için yabancı anahtarlar gerçekten gerekli.

Yabancı anahtarlar, veritabanınızı daha önce görmemiş birinin tablolar arasındaki ilişkiyi belirlemesine izin verir.

Şu anda her şey yoluna girebilir, ancak programcınız ayrıldığında ve başka birinin devralması gerektiğinde ne olacağını düşünün.

Yabancı anahtarlar, binlerce kod satırında gezinmeden veritabanı yapısını anlamalarını sağlar.

Bildiğim kadarıyla, programcının verileri doğru şekilde değiştirmesine yardımcı olmak için yabancı anahtarlar kullanılıyor.

FK'ler, DBA'nın veri bütünlüğünü, programcı başarısız olduğunda kullanıcıların beceriksizliğinden korumasına ve bazen programcıların beceriksizliğine karşı korumasına izin verir.

Bir programcının bunu zaten doğru şekilde yaptığını varsayalım, o zaman gerçekten yabancı anahtar kavramına ihtiyacımız var mı?

Programcılar ölümlü ve yanılabilir. FK'ler bildirimseldir ve bu da onları batırmayı zorlaştırır.

Yabancı anahtarların başka kullanımları var mı? Burada bir şey mi kaçırıyorum?

Bu yüzden yaratılmadıkları halde, FK'ler diyagram oluşturma araçları ve oluşturucuları sorgulamak için güçlü ve güvenilir ipuçları sağlar. Bu, umutsuzca güçlü ve güvenilir ipuçlarına ihtiyaç duyan son kullanıcılara aktarılır.

Emniyet kemerlerinin kesinlikle gerekli olmaması nedeniyle kesinlikle gerekli değildir. Ancak sizi veritabanınızı bozan aptalca bir şey yapmaktan gerçekten kurtarabilirler.

Bir FK kısıtlama hatasını ayıklamak, uygulamanızı bozan bir silme işlemini yeniden oluşturmaktan çok daha güzeldir.

Bunlar önemlidir, çünkü uygulamanız veri tabanındaki verilerin işlenmesinin tek yolu değildir. Uygulamanız bilgi tutarlılığını istediği kadar dürüst bir şekilde ele alabilir, ancak gereken tek şey, veri tabanı düzeyinde bir ekleme, silme veya güncelleme komutu verme ve veri tabanı düzeyinde bir ekleme, silme veya güncelleme komutu vermek için doğru ayrıcalıklara sahip bir bozo yapmaktır ve tüm uygulama referans bütünlüğü zorunluluğunuz atlanır. FK kısıtlamalarını veritabanı seviyesinde koymak, bu bozonun komutlarını vermeden önce FK kısıtlamasını devre dışı bırakmayı seçmesinin engellenmesi, FK kısıtlamasının hatalı bir ekleme / güncelleme / silme ifadesinin bir bilgi bütünlüğü ihlaliyle başarısız olmasına neden olacağı anlamına gelir.

Ben maliyet / fayda ... In açısından düşünmek MySQL bir kısıtlama ekleme tek ek çizgidir, DDL . Bu sadece bir avuç anahtar kelime ve birkaç saniyelik düşünce. Bence tek "maliyet" bu ...

Araçlar yabancı anahtarları sever. Yabancı anahtarlar, iş mantığını veya işlevselliğini etkilemeyen kötü verileri (yani artık satırları) önler ve bu nedenle fark edilmeden ve birikerek birikir. Ayrıca, şemaya aşina olmayan geliştiricilerin bir ilişkiyi kaçırdıklarının farkına varmadan tüm iş parçalarını uygulamalarını da engeller. Belki de mevcut uygulamanızın kapsamı dahilinde her şey harika, ancak bir şeyi kaçırdıysanız ve bir gün beklenmedik bir şey eklediyseniz (süslü raporlamayı düşünün), başlangıçtan beri biriken kötü verileri manuel olarak temizlemeniz gereken bir noktada olabilirsiniz. veritabanı zorunlu denetimi olmadan şemanın.

Bir şeyleri bir araya getirirken halihazırda kafanızda olanı kodlamak için gereken az zaman, sizi ya da bir başkasını yolda aylarca ya da yıllarca kederden kurtarabilir.

Soru:

Yabancı anahtarların başka kullanımları var mı? Burada bir şey mi kaçırıyorum?

Biraz yüklü. "Yabancı anahtarlar" yerine yorumlar, girinti veya değişken adlar ekleyin ... Söz konusu şeyi zaten tam olarak anladıysanız, bu sizin için "faydasızdır".

Entropi azaltma. Veritabanında kaotik senaryoların oluşma potansiyelini azaltın. Tüm olasılıkları göz önünde bulundurduğumuz için zor anlar yaşıyoruz, bu yüzden bence entropi azaltımı herhangi bir sistemin sürdürülmesinin anahtarıdır.

Örneğin bir varsayımda bulunduğumuzda: her siparişin, varsayımın bir şey tarafından uygulanması gereken bir müşterisi vardır . Veritabanlarında "bir şey" yabancı anahtarlardır.

Bunun geliştirme hızındaki ödünleşmeye değer olduğunu düşünüyorum. Elbette, onlarla daha hızlı kod yazabilirsiniz ve muhtemelen bu yüzden bazı insanlar bunları kullanmaz. Şahsen, NHibernate ve bazı işlemleri gerçekleştirdiğimde sinirlenen bazı yabancı anahtar kısıtlamaları ile birkaç saat öldürdüm . ANCAK, sorunun ne olduğunu biliyorum, bu yüzden daha az sorun. Normal araçlar kullanıyorum ve bu konuda çalışmama yardımcı olacak kaynaklar var, muhtemelen yardım edecek insanlar bile!

Alternatif, yabancı bir anahtarın ayarlanmadığı ve verilerinizin tutarsız hale geldiği durumlarda bir hatanın sisteme girmesine izin vermektir (ve yeterli zaman verildiğinde olur). Ardından, alışılmadık bir hata raporu, araştırma ve "OH" alırsınız. Veritabanı çuvalladı. Şimdi bunun düzeltilmesi ne kadar sürer?

Yabancı anahtarları bir kısıtlama olarak görüntüleyebilirsiniz,

• Veri bütünlüğünü korumaya yardımcı olun
• Verilerin birbiriyle nasıl ilişkili olduğunu gösterin (bu, iş mantığı ve kurallarının uygulanmasına yardımcı olabilir)
• Doğru kullanılırsa, verilerin tablolardan getirilme verimliliğini artırmaya yardımcı olabilir.

Şu anda yabancı anahtar kullanmıyoruz. Ve çoğunlukla pişmanlık duymuyoruz.

Bununla birlikte, her ikisi de benzer nedenlerden dolayı, yakın gelecekte bunları çok daha fazla kullanmaya başlayacağımızı söyledi:

1. Diyagram. Doğru kullanılan yabancı anahtar ilişkileri varsa, bir veritabanının diyagramını oluşturmak çok daha kolaydır.

2. Araç desteği. Düzgün yabancı anahtar ilişkileri varsa LINQ to SQL için kullanılabilen Visual Studio 2008 kullanarak veri modelleri oluşturmak çok daha kolaydır .

Bu yüzden sanırım demek istediğim, çok fazla manuel SQL çalışması yapıyorsak (sorgu oluşturma, sorgu çalıştırma, blahblahblah) yabancı anahtarların gerekli olmadığını gördük. Araçları kullanmaya başladığınızda, çok daha kullanışlı hale gelirler.

Yabancı anahtar kısıtlamaları (ve genel olarak kısıtlamalar) ile ilgili en iyi şey, sorgularınızı yazarken bunlara güvenebilmenizdir. "True" tutan veri modeline güvenemezseniz, birçok sorgu çok daha karmaşık hale gelebilir.

Kodda, genellikle bir yerde bir istisna atılır - ancak SQL'de genellikle sadece "yanlış" yanıtları alırız.

Teoride, SQL Server kısıtlamaları bir sorgu planının bir parçası olarak kullanabilir - ancak bölümleme için kontrol kısıtlamaları dışında, buna gerçekten şahit olduğumu söyleyemem.

Üzerinde çalıştığım projelerde (iş uygulamaları ve sosyal ağ siteleri) yabancı anahtarlar hiçbir zaman açıkça belirtilmemişti (YABANCI ANAHTAR REFERANSLAR tablosu (sütun)).

Ancak her zaman yabancı anahtarlar olan sütunların adlandırılmasına ilişkin bir tür kural vardı.

Veritabanı normalleştirmesinde olduğu gibi - ne yaptığınızı ve bunun sonucunun ne olduğunu bilmeniz gerekir (esas olarak performans).

Yabancı anahtarların avantajlarının (veri bütünlüğü, yabancı anahtar sütunu için dizin, veritabanı şemasından haberdar araçlar) farkındayım, ancak aynı zamanda genel kural olarak yabancı anahtarları kullanmaktan korkuyorum.

Ayrıca, çeşitli veritabanı motorları, yabancı anahtarlara farklı bir şekilde hizmet edebilir ve bu, geçiş sırasında küçük hatalara yol açabilir.

ON DELETE CASCADE ile silinen istemcinin tüm siparişlerini ve faturalarını kaldırmak, güzel görünümlü, ancak yanlış tasarlanmış veritabanı şemasının mükemmel bir örneğidir.

Evet. ON DELETE [RESTRICT | CASCADE], geliştiricilerin verileri zor durumda bırakmasını engelleyerek verileri temiz tutar. Yakın zamanda yabancı anahtarlar gibi veritabanı kısıtlamalarına odaklanmayan bir Rails geliştiricileri ekibine katıldım.

Şans eseri, bunları buldum: http://www.redhillonrails.org/foreign_key_associations.html - RedHill on Ruby on Rails eklentileri , yapılandırma stili üzerinden kuralı kullanarak yabancı anahtarlar üretir . Product_id ile bir geçiş , ürünler tablosundaki kimlik için bir yabancı anahtar oluşturacaktır .

İşlemlere sarılmış geçişler dahil olmak üzere RedHill'deki diğer harika eklentilere göz atın .

Veri erişim kodunuzu, yani Entity Framework veya başka bir ORM oluşturmayı planlıyorsanız, Yabancı Anahtarlar olmadan hiyerarşik bir model oluşturma yeteneğini tamamen kaybedersiniz.