İlişkisel veritabanlarındaki kısıtlamalar - Neden bunları tamamen kaldırmıyorsunuz?

Günümüzde tablolar (SQLserver içinde) arasında kısıtlamalar oluşturmak için herhangi bir neden var mı? Varsa ne zaman? Bölgemdeki uygulamaların çoğu nesne ilkeleri üzerine kuruludur ve tablolar isteğe bağlı olarak birleştirilir. Talep, uygulamadan gelen ihtiyaca dayanmaktadır. Basit bir arama için bir dizi kısıtlanmış tablo yüklemeyeceğim, bu da (eylemden sonra) birbirinden basit bir arama gerektiriyor.

EntityContext, Linq2Data, NHibernate gibi ORM araçları da kısıtlamaları kendi başlarına halleder, en azından hangi tabloların birbirine ihtiyacı olduğunu bilirsiniz. Sunucu içinde kısıtlamalar yapmak, aynı değişiklikleri iki kez yapmak (zorlamak) ile ilgilidir?

Bu genellikle karar için bir soru değildir, ancak bu veritabanı oldukça farklı tasarlanmıştır. Tasarım düzenli olarak iyi görünüyor, çoğunlukla uygulamalar tarafından kullanılan nesneleri yansıtıyor. Beni rahatsız eden şey, SQLserver içinde "kademeli değil" ile yapılandırılan tüm kısıtlamalar. Bu, yeni veritabanı sorgularını kodlarken "ara ve bul" oynamanız gerektiği anlamına gelir. Bazı durumlarda, tek bir silme işlemi yapmak için 10 düzeye kadar kesin sipariş düzeyi gerekir.

Bu beni şaşırtıyor ve bununla nasıl başa çıkacağımdan emin değilim.

Benim basit dünyamda, bu ortam kısıtlamaların amacını kaybetmesini sağlıyor. Tasarım bilgisi olmadan ana bilgisayarlardan veritabanına erişilirse Tamam.

Bu senaryoda nasıl davranırsınız?
Neden sadece db'den tüm kısıtlamaları kaldırmak ve uygulama düzeyinde tutmak değil?

DB'den kontraksiyonları temizlememenin iki genel nedeni :

• Buna, şimdi veya gelecekte , ORM'yi kullanabilecek veya kullanamayacak daha fazla uygulama tarafından erişilebilir . Bu uygulamaların geliştiricileri oradaki tüm kısıtlamaları sadakatle kopyalasa bile (daha düşük seviyeli ORM olmayan çözümler kullanarak önemli ölçüde daha zor olabilir), her zaman ekstra iştir. Ve değilse, şema bütünlüğünü kırmak için küçük bir ihmal bile yeterlidir ... bu risk almak istemediğiniz bir şeydir. Çoğu şirkette, DB'lerinde depolanan veriler işlerinin can damarıdır, bu nedenle bütünlüğü herhangi bir şekilde sağlanmalıdır. Ve bunu başarmak için denenmiş ve kanıtlanmış en iyi yol, DB'de mümkün olduğunca çok kısıtlama uygulamaktır.
• Sorgu iyileştirici, DB düzeyinde bilinen kısıtlamalara çok güvenir. Kısıtlamaları kaldırırsanız, sorgu performansı düşmeye başlayabilir . Hemen fark edemeyebilirsiniz, ancak bir gün size çarpacak ve o zamana kadar kolayca düzeltmek için çok geç olabilir. İşlerin doğası, DB performansının, kesin performans ölçümleri ve kök nedenleri belirlemek için ayrıntılı analizlerle desteklenen dikkatli, iyi düşünülmüş tasarım geliştirmeleri yapma olasılığı en düşük olduğunda, yoğun yük zamanında bozulma eğilimindedir.

DB şemanızın orijinal olarak bir ORM aracı tarafından oluşturulmuş (veya ilişkisel dünyayla çok deneyimli olmayan biri tarafından tasarlanmış) gibi somut durumunuz, bu nedenle ilişkisel bakış açısından yetersizdir. ORM görünümleriyle tutarlı tutarken, onu daha "doğal" bir ilişkisel tasarıma doğru analiz etmek ve geliştirmek muhtemelen daha iyidir. Bu analize bir DB uzmanının dahil edilmesi yararlı olabilir.

Uygulamalar gelip gidebilir ancak veriler sonsuza dek yaşar. Şirketimde DB 30-40 yaşın üzerinde, şirket var olduğu sürece devam edecek. Uygulamalar değişir, geliştiriciler gelir ve gider. Bütünlüğe ve iyi bir mantıksal veri modeline sahip olmak daha iyidir. Bu şekilde, birisi karmaşık bir kod tabanından geçmek zorunda kalmadan verilere bakabilir ve anlamlı bir anlayış kazanabilir. Bu da raporlamanın önemli ölçüde yapılmasına yardımcı olur. Ayrıca uygulamalar böcek olabilir ve olacak ve DB kısıtlaması buna karşı bir koruyucudur. Varsayılan konumum olabildiğince çok kısıtlamaya (FK ve kontrol) sahip olmak.
Bir kısıtlamanın olmamasının tek nedeni, tasarım deseninizin, örneğin hiyerarşi başına tablo veya performans sorunlarına izin vermemesi olabilir.

Beni rahatsız eden şey, SQLserver içinde "kademeli değil" ile yapılandırılan tüm kısıtlamalar.

Bu beni rahatsız etmiyor, birisinin iyi bir anlam gösterdiği anlamına geliyor. Basamaklı silmeler veritabanı için genellikle çok kötüdür. İlk olarak, bazen ilişkili tablolarda verileriniz varsa silme işleminin başarısız olmasını istersiniz. Örneğin, geçmişte bir siparişi olan bir müşteriniz varsa, onun silinmesini istemezsiniz veya siparişin kim için olduğu ile ilgili verileri kaybedersiniz ve kademeli bir silme woudl finansal raporunuzu bozacak kayıttan kurtulur .

Gelişim kolaylığının en önemli şey olduğunu düşünüyor gibisiniz. Veritabanı dünyasında bu doğru değildir. Veri bütünlüğü, performans ve veri güvenliğini yakından takip eden ilk en kritik şeydir. Sorguları yazmak daha uzun sürüyorsa, öyle olsun.

Veritabanı genellikle birçok uygulama tarafından çalıştırılır = bir veya daha fazla web sitesi veya masaüstü uygulaması, bir raporlama uygulaması, web hizmetleri, sorgu penceresi, ETL işlemleri vb. Veritabanı düzeyinde çelişkiler uygulamazsanız öncelikle bütünlüğü kaybedersiniz Bu uygulamalardan biri olarak verilerin tüm kurallara uymayabilir. İkincisi, daha sonra farklı bir uygulama kullanmaya karar verirseniz, bu karşıtlıkları birkaç kez kodlamanız ve yeniden yazmanız gerekir. Üçüncüsü, uygulamada gerçekleşmeyecek bir tür veri bakım görevinin yapılması gerekip gerekmediğini önceden kontrol edemezsiniz (örneğin, kötü bir müşteri verisi içe aktarmasından gelen verileri düzeltme veya bir istemciden tüm 10.000.000 kaydı değiştirme şirket bir rakip tarafından satın alındığında başka bir müşteriye). Genellikle uygulama geliştiricileri

Bir kez temelde şunu söyledi bir yerde okudum: Veri uygulamanızın anahtarıdır . Eğer olacak sizin kullanıcı arayüzü aracılığıyla yalnızca HİÇ erişim verilerini (ve demek hiç Şimdi ve sonsuza dek olduğu gibi, sonsuza ... ya neyse Başvurunuzun ömrü için) o zaman gerek yoktur veritabanı kısıtları. Ancak, uygulamanın kendisinden başka bir şeyin, örneğin bir web hizmeti, genel API, komisyon görevi / SQL işi / cron / otomatik komut dosyası gibi verilere dokunması gerektiğine dair bir şans var, o zaman kendinizi çok fazla potansiyel sorundan kurtaracaksınız. DB kısıtlamalarını koruyarak yol.

Ben sıkıca size gereken yerde bu yazılım geliştirme bir alan olduğuna inanıyoruz değil DRY uygulamak (ve ben tam o deyimi için downvotes bir kuş sürüsü bekliyorum). Verileriniz uygulamanızın kalbi ve ruhudur - onarılamayacak kadar bozulmuşsa, oyun biter. İhtiyaç duydukları her yerde kısıtlamaları uygulamak IMO'ya değer. Bu, DB düzeyindeki Tetikleyiciler ve kısıtlamalar, ara katmandaki sunucu tarafı doğrulamaları ve kullanıcı arayüzündeki istemci tarafı Javascript'i (web uygulamaları için) şeklinde ise, verilerin her zaman bozulmamış olmasını sağlamak için IMO gerekli bir kötülüktür. .

ORM'nin ne anlama geldiğini biliyor musunuz? Nesne-ilişkisel haritalama. Wikipedia " uyumsuz tip sistemler arasında veri dönüştürme tekniği ". Evet, ilişkisel ve nesne modelleri birbirine uymuyor. ORM'ler her iki tip sistemin kurallarına saygı göstererek oldukça iyi bir dönüşüm gerçekleştirir. RDBMS, kısıtlamaları kullanarak veri bütünlüğünü sağlayacak şekilde düzenlenmiştir. Genel olarak, bütünlük çok güzel bir şeydir, bu nedenle ORM'ler bunları nesne verilerini depolamak için veri modeli oluştururken kullanma eğilimindedir. ORM'nizin muhtemelen "basamaklı olmayan" kısıtlamaları kullanmak için iyi bir nedeni vardır. Ve bu, sizi yalnızca belirli nesneleri oluşturmak / güncellemek / bırakmak yerine karmaşık sorgular yapmaya zorlarsa, ORM kurulumunuzda bir sorun vardır.

İlişkisel kavramın can sıkıcı olduğunu düşünüyorsanız, neden nesne veritabanını kullanmıyorsunuz? Bir süre önce yavaşlardı (bu yüzden çoğu insan hala RDBMS kullanıyor) ama duyduğumdan biraz değişti. Bütün ilişkisel nitpicks kurtulmak. Basitçe içeri girer, dışarı çıkar.

İşte eBay bunu yaptı ve muhtemelen dünyanın en büyük veritabanlarından birine sahipler:

http://www.dba-oracle.com/oracle_news/news_ebay_massive_oracle.htm http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf

Performansın referans bütünlüğü ile artırılması hakkında yukarıda söylenenlere rağmen, aslında bozulabilir; bu yüzden büyük veritabanları kısıtlamalarını bırakıyor ve uygulama katmanındaki işi yapıyorlar. Ve anlayabildiğim kadarıyla tek gerçekten iyi bir neden.

Bu kısıtlamaları bırakarak, verileri temiz tutan ve bu da kendi sorunlarını ortaya çıkaran güvenlik ağınızı kaybedersiniz. Her şeyde olduğu gibi dengeleyici bir eylemdir. Genel olarak referans bütünlüğünün korunması yapılacak doğru şeydir.

Güçlü bir referans bütünlüğüne sahip bir geliştirme ortamında çalıştıktan sonra, geliştiricinin bakış açısından bunun tam bir acı olabileceğini biliyorum; genellikle bir geliştirme ortamında biraz kirli veri önemli değildir ve bir satırın nasıl silineceği bir saat veya daha fazla sürebilir. Bununla birlikte, kısıtlamalar şemayı açık hale getirdiğinden, çok yararlı olabilir.

İlk olarak - cevabım: Hayır, verilerinize bakmak için sadece uygulamaya güvenmemelisiniz.

Bu daha büyük bir tartışmaya işaret ediyor: ORM'ler, genellikle normalleşme / referans bütünlüğü pahasına "doğrudan" DB etkileşimi için küçümseme kültürünü teşvik ettiler. Tablolar, ilişkisel modelde örtülü tasarım pahasına zorla keyfi nesne hiyerarşilerine eşlenir. OOP tarafından tercih edilen ayrılma burada tartışılır bir şekilde feda edilir, çünkü uygulama tasarımını veri yapısında hissettirir. ORM büyük yarar gösterdi, ancak SQL kötüye kullanımı veya güvensizliği dayalı gibi görünüyor.

Yeni paradigmalar ortaya çıkıyor (örneğin) Fonksiyonel programlama. Geliştirici ekibi yeni bir programlama metodolojisini benimsemeye karar verirse, bunun ORM gereksinimlerine göre yapılandırılmış veriler için ne gibi etkileri olacaktır?

@Jacek Prucia ile hemfikirim - ORM'nin RDBMS için kötü bir eşleşme olduğunu düşünüyorum, şahsen RDBMS'de bir DBAL'yi seçerim veya ORM'li bir OODB'ye giderim.

Kısıtlamalar, veritabanı düzeyinde tutarlılık ve veri bütünlüğüne sahip olduğunuzun tek garantisidir. Tabii, uygulama kodunuzu kullanarak kısıtlamalar uygulayabilirsiniz, ancak gelecekte verileri doğrudan değiştirmeniz gerekirse ne olur? Veri bütünlüğünü nasıl koruyacağınızı anlayabilirsiniz, ancak bir başkası olmayabilir. Kısıtlamaları veri düzeyinde tutmak, biri anlamadığı yerlerde dolaşırken bile bütünlüğün sağlanmasını sağlar.

Ayrıca, uygulamanızın yeniden yazılması gerektiğini, ancak aynı veritabanının yerinde olduğunu varsayalım. Koddaki tüm bu kısıtlamalar, hatalı veriye izin verirken bazı girişleri engelleyen hatalar için yalvarıyor.

Gelişirken basit tutun. Kısıtlamalar bunu yapmanıza izin verir. (Bir sınırlama hata verdiğinde, aynı hatayı kullanıcıya geri tükürmeyin. Hatayı anlaşılır yapın.)

(Basamaklı konuya gelince: bu iyi bir şey. Her şeyi doğru yapmak için basamağa güvenmek yerine ilk önce bazı diğer kayıtların silinmesi gerektiği şeklinde bir hata atmayı tercih ederim. pratikte.)

Veritabanındaki kısıtlamalarla ilgili bir sorun, programın neyin başarısız olduğu ve nasıl düzeltileceği hakkında sınırlı bilgi vermesidir. Bu, düzgün kullanım için, kısıtlama kontrolünün uygulamada tekrarlanması gerektiği ve dolayısıyla veritabanı kısıtlama kontrolünün boşa harcandığı anlamına gelir.

Bu, veri bütünlüğünden taviz verme riskini taşır, bu yüzden burada ödünleşmelerimiz var. Önemli veriler için, veri bütünlüğünün sağlanması neredeyse her zaman performanstan daha önemlidir ve verileri karıştırmak yerine keyfi görünse bile bir işlemde başarısız olmak çok daha iyidir.

Kısıtlamaları güvenli bir şekilde kaldırmak için, hiçbir şeyin kısıtlamaları kontrol etmeden veritabanını değiştiremeyeceği şekilde veritabanı erişimini güvenli hale getirmek çok önemlidir. Yeni uygulamalar yazarken veya verilerle başa çıkmak için özel yollar bulurken bu güvenilir değildir, çünkü tek yapmanız gereken bir hata ve veritabanı bozuktur.

Bu nedenle, veritabanı kısıtlamalarından vazgeçmek için, tüm uygulamaların kapsamlı bir şekilde yazılabilmesi, gözden geçirilebilmesi ve test edilebilmesi için veritabanı ile neyin yapılabileceğini ve nelerin yapılamayacağını belirlemek gerekir. Tüm veritabanı gereksinimleri önceden belirlenmelidir ve veritabanı gereksinimlerindeki herhangi bir değişiklik kapsamlı bir çalışma gerektirir. Bu, sadece çok özel durumlarda çalışan donmuş bir şelale yöntemidir. (Tasarlamak, uygulamak ve gereksinimlere uymak, su üzerinde yürümek gibidir. Önce bir şeyler dondurulmalı ve yeterince donmazsa sonuçlar felaket olabilir.)

İşe yaradığı bir durum, uygulamanın zaten her şeyi yaptığı PeopleSoft ve SAP gibi büyük kurumsal uygulamalar ve onu genişletmek için dikkatlice tanımlanmış yollar var. Çok nadir bulunan başka olasılıklar da vardır.

Bu nedenle, çok büyük bir kurumsal projede (ve ben istemem) çalışmadıkça veya sıvı su üzerinde yürüyemiyorsanız, bu kısıtlamaları veritabanında bırakın.