Veritabanı bütünlüğünü zorlama

Bu, uygulamanın yabancı anahtarlar, kontrol kısıtlamaları vb. Yerine veritabanı bütünlüğünü zorunlu kılması mantıklı olur mu?

Dahili veritabanı araçları aracılığıyla veritabanı bütünlüğünü zorlamamak için ne kadar performans artışı beklenebilir?

Gerçek şu ki, veritabanında yabancı anahtar kısıtlamaları olmaktan çok performans kaybı görmeyecek, aynı zamanda performans geliştirmelerini de göreceksiniz. SQL Server sorgu optimize edici, birincil ve yabancı anahtarlar kavramının yanı sıra diğer veri kısıtlama türleri üzerine kurulmuştur. Bunlar yerinde ve zorlanmışsa, iyileştirici size daha iyi performans elde etmek için bunlardan yararlanabilir. İşte bunu gösteren basit bir örnek içeren bir blog yazısı .

Gerçekten okumalardan daha fazla ekin bulunduğu bir kenar durumundaysanız (ve güncellemeler ve silmeler okuma gerektirir, bu nedenle genellikle okuma sayısına eklenirler), performans için verilerden kısıtlamaları kaldırmak mantıklı olabilir, belki . Ancak, veritabanlarının ezici çoğunluğu okuma odaklı olduğundan, performansı artırmazsınız, performansı arttırmazsınız.

Ve bunların hiçbiri, veri bütünlüğünün veritabanında daha iyi ele alındığı gerçeğinden bahsetmez, çünkü yalnızca bir kez oluşturmanız gerekir; burada, koddaki tüm işi yaparsanız, birden fazla uygulama için birden fazla kez yapmanız gerekebilir ( veri erişim katmanınız dikkatlice ve aynı katmandan geçmek için her uygulamanın db'ye erişmesini gerektirir).

İlişkisel bir veritabanı sistemi kullanıyorsanız, neden gerçekten kullanmıyorsunuz diyorum. İlişkisel verilere ihtiyacınız yoksa Hadoop veya başka bir şeyle gidin.

Birçok uygulama geliştiricisi böyle düşünüyor.

Veri bütünlüğünü uygulama koduna devretmeye hazır olduğunuzda, "Her programcı ve bu veritabanından bugüne kadar vuran her uygulama zamanın sonuna kadar mükemmel bir şekilde doğru yapmak zorunda" diye düşünün.

Olasılıklar nelerdir?

Herhangi bir performans kazancı olsa bile, referans bütünlüğünün ve genelleştirilmiş veri bütünlüğünün geri dönüşüyle ​​karşılaştırıldığında önemsizdir.

Uzun zamandır bir veritabanının aptal bir veri deposu olduğu günler. RDBMS'nin sunduğu güçten yararlanın.

Performans kazançları her şey değildir, özellikle bu kadar küçük ölçekte. Ancak, uygulamanızın zorlaması gereken bir yabancı anahtar ilişkiniz olduğunu öğrendiğinizde ve referans tablosunda birincil bir anahtar olmadığı ortaya çıkıyorsa, performans kazancıyla çok az ilgilenirsiniz (varsa, bunun özellikleri hakkında konuşmayın).

Yeterince büyük bir veri yükü yapıyorsanız kısıtlamaları (yabancı anahtarlar, CHECK vb.) Ve dizinleri bırakmak ve daha sonra kısıtlamaları ve dizinleri yeniden etkinleştirmek / uygulamak yaygın bir uygulamadır. Bu doğrulamanın bir zaman maliyeti vardır. Bu, veritabanına özel toplu yük sözdizimini kullanamayacağınızı varsayar (günlüğü en aza indirme dahil).

Performansta ne kadar artış olacağını beklemek imkansız - her durum benzersizdir (veri türleri, tasarım, vb.). Gerçekten bilmenin tek yolu test etmektir.

Kısıtlamalar engellendiğinde birkaç kez vardır:

1. Tekli Tablo Kalıtım (STI) kullanmanız gerektiğinde . Hem bireylere hem de organizasyonlara sattığınızı düşünün. Satırı bireysel veya kuruluş olan tek bir "Parti" tablosuna ihtiyacınız olacaktır. STI, boş olmaması gereken bazı boş alanlara ihtiyacınız olduğu anlamına gelir. Sınıf Tablosu Devralma bunu çözer, ancak bu bazı ORM'ler için daha zordur. Ruby'nin ActiveRecord'u yalnızca STI'yı destekler.

2. Bir varlığın Taslak sürümlerini desteklemeniz gerektiğinde, bu tamamen geçerli olmayabilir. Bir taslağı json olarak saklayabilirsiniz, ancak daha sonra aynı tanımlayıcıyı istemcide yeniden kullanmak daha zordur - id = 5 ile kaydedildiğini, geçerli olmayacak şekilde düzenlendiğini ve draftid = 99 olarak otomatik olarak kaydedildiğini hayal edin. Bu durumda, tüm alanlarınızın büyük olasılıkla boş değerli olması gerekir.