SQL Server içinde NoSQL

Bu soru SQL ve NoSQL arasındaki farkla ilgili değildir. Şu anda bana gerçekten mantıklı gelmeyen bir şey için bazı sebepler aradım (belki de anlayış veya takdir eksikliğimden dolayı).

MVC5, önce Entity framework 6 kodunu ve SQL Server 2008'i kullanarak sıfırdan yeni bir projeye başladık. Mimar veritabanı şemasını gözden geçirdiğinde, tüm yabancı anahtarların ve bu gibi diğer kısıtlamaların “iş mantığı” olduğu için kaldırılması gerektiği ve başvuru kodunun iş katmanında uygulanmalıdır.

Benim fikrim, yabancı anahtarların veri / referans bütünlüğünün bir parçası olduğu ve iş mantığını gerçekten taklit etmediğidir. İş mantığını, referansların neyin / ne zaman / nasıl / niçin uygulandığını kontrol eden süreç ve doğrulama olarak görüyorum. Eşsiz kısıtlamaların tartışmasız iş süreçleri olduğunu anlayabiliyorum, ama benim için bu sadece mantığı tamamlıyor ve bütünlüğün bir parçasını oluşturuyor.

İkinci bir argüman ise verilere NoSQL yaklaşımı benimsemektir. Bunu gerçekten sıradışı ve sıradışı buldum: SQL-Server 2008'in kullanımı, raporlama ihtiyacı, terabaytlara ölçeklenemeyen veriler ve Mongo, Raven, vb. Gibi teknolojilere yönelik dikkat eksikliği.

Daha önce böyle bir senaryo ile karşılaşan var mı? Neden birileri referans verileri için tasarlanmış ve yabancı anahtar istemeyecek bir SQL Server'da bir NoSQL yaklaşımı benimsemelidir?

Veri tabanı şemasını gözden geçirirken, bu iş mantığı olduğu için tüm yabancı anahtarların ve bu gibi diğer kısıtlamaların kaldırılması gerektiğini ve iş katmanında uygulanması gerektiğini belirtti.

O zaman bir aptal, ve kod üssünüzden bazı alıntılar bir gün Daily WTF'de sona eriyor . Onun yaklaşımının bir anlam ifade etmediği konusunda haklısın ve açıkçası onun da açıklaması yok.

Ona referans bütünlüğü kısıtlamalarının "iş mantığı" olmadığını; onlar konum kendi yerleşik doğrulama ile bir doğruluk standardı. İş mantığı, verilerle ne yaptığınızla ilgilidir; bütünlük , verilerin kendisinin bozulmamasını sağlamakla ilgilidir. Ve bu işe yaramazsa ... iyi o sorumlu. Ya onun planı ile devam edebilir ve hasarı biraz hafifletmeye çalışabilir ya da çalışmak için daha iyi bir yer aramaya başlayabilirsiniz. (Ya da her ikisi de.)

Yabancı anahtar oluşturmak için bir nedenim olmadı.

- Joel Spolsky

Battaniye açıklamaları bir yana, özgünlük veya yabancı anahtar kısıtlamaları kullanmamayı seçmenin meşru ve güçlü nedenleri olduğunu kabul etmeye değer. Çoğu böyle bir şey gitmek:

• Performans.Atomik işlemlerle bütünlük kontrolü yapmak ücretsiz değildir. Ve sık sık, veritabanı mimarisinin ölçeklenmesi en zor kısmıdır. Muhtemelen kontrolleri uygulama mantığınızda zaten yaptınız ve ikinci bir performansa ulaşmayı tercih etmediniz.
• İhtiyaç eksikliği. Belki de verileriniz kirli ve bu konuda sorun yok. Bu ne yaptığınıza çok bağlıdır.

Ayrıca bakınız Yabancı anahtarların nesi var?

Ancak bunlar, sorunuzdaki nedenlerle eşleşmiyor.

Bu iş mantığıdır ve iş katmanında uygulanmalıdır.

Bu sebep biraz garip. Benzersizlik ve diğer bütünlük kısıtlamaları, bir ACID veritabanının alanıdır. Uygulama kodunuz, SQLServer'ın atomik ve bütünlük garantilerine yaklaşamıyor. Güçlü bir veri bütünlüğüne ihtiyacınız varsa, veritabanını yok saymanız aptallık olur.

İkinci bir argüman, NoSQL yaklaşımını veri depolama alanlarına uyarlamak istedikleri ve bu tür kısıtlamaları yerine koymak istemedikleridir.

İkinci sebep, gerçekten bir sebep değil; bu bir sonuçtur. Kısıtlamaların doğruluk ve performans arasında bir denge olduğu doğru olsa da, NoSQL veritabanları ikincisine karşı önyargılıdır.

Belki de sistem mimarınız bu meşru sebepleri aklınızda tutar ve siz de karıştınız. Ya da belki o patlayan bir aptal.

Her durumda, geçerli benzersiz ve yabancı anahtar kısıtlamaları kullanmaktan kaçınmak evrensel da ) sebepler vardır.

Not Eğer yabancı anahtarlar istemediğinize karar verirseniz, ilişkisel bir veritabanı kullanmak hala tamamdır. Genelleme olarak, ilişkisel veritabanları NoSQL benzerlerinden daha olgunlaşmıştır. Tek bir düğüm olarak, daha da hızlı olabilirler ve bunların üzerine bir NoSQL soyutlaması oluşturulabilir .