Veritabanı kısıtlamalarına ne oldu?

RDBMS için veritabanı modellerini incelerken, genellikle çok az veya hiç kısıtlama bulunmadığına şaşırdım (PK / FK dışında). Örneğin, yüzde genellikle bir tür sütununda saklanır int( tinyintdaha uygun olurken ) ve CHECKdeğeri 0..100 aralığına sınırlamak için herhangi bir kısıtlama yoktur . Benzer şekilde, SE.SE'de, kontrol kısıtlamalarını öneren cevaplar sıklıkla veritabanının kısıtlamalar için yanlış bir yer olduğunu öne süren yorumlar alır .

Kısıtlamaları uygulamama kararını sorduğumda, ekip üyeleri cevap veriyor:

• Ya da bu özelliklerin kendi favori veritabanlarında bulunduğunu bile bilmiyorlar. Yalnızca ORM kullanan programcılardan anlaşılır, ancak belirli bir RDBMS ile 5+ yıllık bir deneyime sahip olduğunu iddia eden DBA'lardan çok daha az anlaşılabilir.

• Veya bu kısıtlamaları uygulama düzeyinde uyguladıkları ve bu kuralları veritabanında çoğaltmaları, SSOT'u ihlal etmenin iyi bir fikir olmadığını göstermektedir.

Son zamanlarda, yabancı anahtarların bile kullanılmadığı daha fazla proje görüyorum. Benzer şekilde, SE.SE hakkında , kullanıcıların başvuru bütünlüğünü önemsemediğini ve uygulamanın onu idare etmesine izin vermediğini gösteren birkaç yorum gördüm .

Ekiplere FK kullanmama seçimleri hakkında sorular sorulduğunda, şunu söylüyorlar:

• Örneğin, diğer tablolarda referans verilen bir öğeyi kaldırmak zorunda olduğunda PITA'dır.

• NoSQL kayalar ve orada yabancı anahtar yoktur. Bu nedenle, RDBMS'de onlara ihtiyacımız yok.

• Performans açısından büyük bir sorun değil (bağlam genellikle küçük veri kümeleri üzerinde çalışan küçük intranet web uygulamalarıdır, bu nedenle, aslında endeksler bile çok fazla önemli olmaz; verilen bir sorgunun performansının 1,5 saniyeden fazla geçmesi durumunda kimse umursamaz. ... ila 20 msn.)

Uygulamanın kendisine baktığımda, sistematik olarak iki modeli görüyorum:

• Uygulama, verileri düzgün şekilde temizler ve veritabanına göndermeden önce kontrol eder. Örneğin 102, uygulama aracılığıyla bir değeri yüzde olarak kaydetmenin bir yolu yoktur .

• Uygulama veritabanından gelen tüm verilerin tamamen geçerli olduğunu varsayar. Yani, 102yüzde olarak gelirse, ya bir şey, bir yer çökecek ya da sadece kullanıcıya olduğu gibi gösterilecek ve garip durumlara yol açacaktır.

• Sorguların% 99'undan fazlası tek bir uygulama tarafından yapılsa da, zaman içinde komut dosyaları görünmeye başlar; gerektiğinde komut dosyaları el ile koştu veya cron işleri. Bazı veri işlemleri de veritabanının üzerinde el ile gerçekleştirilir. Hem komut dosyaları hem de manuel SQL sorguları, geçersiz değerler sağlama riskini yüksek tutar.

Ve işte sorum geliyor:

İlişkisel veritabanlarını kontrol kısıtlamaları olmadan ve sonunda yabancı anahtarlar olmadan bile modellemenin sebepleri nelerdir?

Buna değer, bu soru ve aldığım cevaplar (özellikle Thomas Kilian ile olan ilginç tartışma) veri tabanı kısıtlamaları konusundaki sonuçlarımla ilgili bir makale yazmamı sağladı .

Veritabanları için farklı kullanım durumları arasında ayrım yapmak önemlidir.

Geleneksel iş veritabanına çoklu bağımsız uygulamalar ve hizmetler ve belki de doğrudan yetkili kullanıcılar tarafından erişilir. Veri tabanı düzeyinde iyi düşünülmüş bir şema ve kısıtlamalar olması çok önemlidir, bu nedenle tek bir uygulamadaki bir hata veya gözetim veritabanını bozmaz. Veri tabanı iş açısından kritiktir, bu da tutarsız veya bozuk verilerin iş için feci sonuçlar doğurabileceği anlamına gelir. Uygulamalar gelip giderken veriler sonsuza dek yaşayacak. Bunlar, veri tabanının tutarlılığını ve sağlığını sağlamak için özel bir DBA'ya sahip olabilecek yerlerdir.

Ancak, veritabanının tek bir uygulamayla sıkı bir şekilde bütünleştirildiği sistemler de vardır. Tek başına katıştırılmış uygulamalar veya tek bir gömülü veritabanına sahip web uygulaması. Veritabanına yalnızca tek bir uygulama tarafından erişildiği sürece, uygulama düzgün çalıştığı sürece, kısıtlamaları gereksiz olarak düşünebilirsiniz. Bu sistemler genellikle uygulama koduna odaklanan ve belki de ilişkisel model hakkında derin bir anlayışa sahip olmayan programcılar tarafından geliştirilmiştir. Eğer uygulama bir ORM kullanıyorsa, kısıtlamalar uygulama programcılarına daha aşina bir biçimde ORM seviyesinde ilan edilebilir. Sonunda MySQL kullanan PHP uygulamalarımız var ve uzun süredir MySQL temel kısıtlamaları hiç desteklemedi, bu nedenle tutarlılığı sağlamak için uygulama katmanına güvenmek zorunda kaldı.

Bu farklı kökenden gelen geliştiriciler bir araya geldiğinde bir kültür çatışması yaşarsınız.

Bu karışıma dağıtılmış "bulut depolama" veritabanlarının yeni dalgasını alıyoruz. Performans avantajını kaybetmeden dağıtılmış bir veritabanını tutarlı tutmak çok zordur, bu nedenle bu veritabanları genellikle veritabanı düzeyinde tutarlılık kontrollerinden kaçınır ve temelde programcıların uygulama düzeyinde yönetmesine izin verir. Farklı uygulamaların farklı tutarlılık gereksinimleri vardır ve Googles arama motoru, sunucularında tutarlılık yerine kullanılabilirliği öncelik sırasına koyarken, maaş bordro sistemlerinin çok sayıda kısıtlı ilişkisel bir veritabanı üzerinde çalışacağına bahse girerim.

Günümüzde gittikçe artan sayıda sistem bulut üzerinde dağıtık ortamlarda çalışmakta ve “ölçeklendirme” yerine “ölçeklendirme” tekniğini benimsemektedir. E-ticaret uygulamaları gibi internete bakan uygulamalarla ilgileniyorsanız, bu daha da önemli.

Söylenmesi gereken, ölçeklendirilmesi gereken tüm uygulamalar, CAP Teoremi ile sınırlandırılmıştır , burada 3 / 2'yi seçmeniz gerekir: Tutarlılık, Kullanılabilirlik ve Bölüm Toleransı (ağ hatası toleransı).

CAP Teoremini inceleyerek çok fazla seçenek olmadığını göreceksiniz, fakat Kullanılabilirliği veya Tutarlılığı kaybetmeyi seçmelisiniz, çünkü Ağa ASLA% 100 oranında ASLA güvenemeyeceksiniz.

Genel olarak, birkaç uygulama makul bir süre boyunca tutarsız olabilir, ancak kullanıcılar tarafından kullanılamayabilir. Örneğin, Facebook veya Twitter'da biraz sıralanmamış bir zaman çizelgesi, bir zaman çizelgesine hiç erişememekten daha iyidir.

Bu nedenle, çeşitli uygulamalar ilişkisel veritabanı kısıtlamalarını bırakmayı seçmektedir, çünkü ilişkisel veritabanları Tutarlılıkta gerçekten iyi, ancak uygunluk pahasına.

Kişisel not: Ben de eski modayım ve veri tutarlılığının çoğu zaman birinci sınıf bir gereksinim olduğu bazı eski finansal sistemlerle çalışıyorum ve veri tabanı kısıtlamalarının büyük bir hayranıyım. Veri tabanı kısıtlamaları, yıllar süren kötü gelişme ve gelip giden geliştirici ekiplerine karşı son savunma hattıdır.

Msgstr "Rebus'taki tahmini mod". Tutarlılığın birinci sınıf bir gereksinim olduğu DB "düşük seviye" tutarlılığını kullanmaya devam edelim. Ama bazen, bırak gitsin sonuçta büyük bir günah değildir.

-- DÜZENLE: --

Soruda küçük bir düzenleme yapıldığından, IMO veritabanındaki kısıtlamaları bırakmak için başka bir meşru sebep var. Sıfırdan bir ürün tasarlarsanız, sisteminizi çoklu veritabanı teknolojisini destekleyecek şekilde tasarlarsanız, desteklenen veritabanları arasında en az ortak payda belirleyebilir ve sonuçta tüm kontrollerin kullanılmasını engelleyebilir ve tüm kontrol mantığını bırakabilirsiniz. başvurunuz.

Meşru olmasına rağmen, bu da benim için gri bir alan çünkü bugün orijinal soruda önerilenler gibi basit kısıtlamaları desteklemeyen herhangi bir veritabanı motoru bulamıyorum.

İlişkisel veritabanlarını kontrol kısıtlamaları olmadan ve sonunda yabancı anahtarlar olmadan bile modellemenin sebepleri nelerdir?

Öncelikle burada, SQL olmayan veritabanları hakkında değil, sadece RDBM'ler hakkında konuştuğumu anlatayım.

FK veya PK olmayan birkaç veri tabanı gördüm, kısıtlamaları kontrol etmemize rağmen dürüst olmak gerekirse azınlıktırlar. Belki de büyük bir şirkette çalışıyorum.

Yıllar boyunca edindiğim tecrübelerime göre, bazı nedenlerin şöyle olabileceğini söyleyebilirim:

• Durumunda başlayanlar veya hobi programcılar, diğerleri modelleme becerilerinin ack
• Veri tabanı dünyasıyla gerçek teması olmayan ORM'lerin kapsamlı veya neredeyse özel kullanımı
• Bir takım veya küçük projede DBA veya başka bir veri modelleme uzmanının olmaması
• Gelişimin ilk aşamalarında DBA'nın veya veri modelleme uzmanının katılımının olmaması
• Kasıtlı tasarım kararları güçlendiği belli sütun yalnızca sahip olabileceği o hatta bir denetim kısıtlaması gördüğü geliştirici topluluğuna kısmı tarafından 1,2 or 3"yaş" sütunu olması gereken bir değer olarak veya bu >= 0edilmektedir "veritabanında iş mantığını sahip" . Varsayılan maddeler bile, bazıları tarafından bir veritabanına ait olmayan iş mantığı olarak kabul edilir, çünkü bu sitedeki son birkaç soru ve cevapta görebilirsiniz. Bu yüzden düşünen bu geliştiriciler, açıkçası mümkün olduğunca az kısıtlama kullanacak ve herşeyi kod içinde, hatta referans bütünlüğü ve / veya birliği bile yapacaklar. Bunun aşırı bir durum olduğunu düşünüyorum.
• RDBM'lerin anahtar-değer depoları olarak kullanılması , ya SQL-olmayan davranışlarını taklit etmek için, çünkü gereklilikleri, anahtar-değer depolarını yalıtmak için RDBMS tablolarını kullanarak yeterince basit olması gereken şartlar.
• Veritabanının her zaman "uygulama" tarafından yazılacağını ve hiç kimsenin büyük bir veri yüklemesi yapmak zorunda kalmayacağını veya bir SQL istemcisi aracılığıyla satırları düzenlemek veya eklemek gerekmeyeceğini varsayarak (çoğu zaman uygulamanın eklediği kötü verileri düzeltmek için). En iyi durumda escenario her zaman veritabanına DML talimatlarını veren başka bir uygulama ("uygulamanın yanı sıra") olacaktır: bir SQL istemcisi.
• Verilerin uygulamaya değil iş sahibine ait olduğunun farkında değil

Bununla birlikte, RDBMS'nin devlerin omuzları üzerine inşa edilmiş ve çok sayıda iş gereksinimi için çok verimli olduğunu kanıtlayan ve bir seri üzerinde referans bütünlüğünü uygulamadaki sıradan görev programcılarını serbest bırakan çok gelişmiş bir yazılım olduğunu belirtmek istiyorum. İkili dosyalar veya metin dosyaları. Her zaman dediğim gibi "artık tek uygulama bir veritabanı dünyasında yaşamıyoruz" . En azından bir SQL istemcisi "uygulamanın" yanı sıra DML yayınlayacak. Bu yüzden veri tabanı kendini insan veya programlama hatalarından makul ölçüde korumalıdır.

RDBMS'nin iyi ölçeklenemeyeceği iyi bilinen bu tür gereksinimlerde, elbette, no-SQL teknolojisini kullanır . Ancak, RDBMS'nin sizin için neyi daha verimli şekilde uygulaması gerektiğine karar vermek için binlerce kod satırının (oluşturulan veya yazılan) kısıtlı olmayan ilişkisel veritabanlarının çoğalması endişelenmektedir.

Teknoloji kararlarını yönlendiren harici kısıtlamalar var. Veri tabanı alanı kısıtlamalarını düzenli olarak kullanma gereksiniminiz veya lüksünüzün olduğu birkaç durum vardır.

1. İşletmeler DBA ile birlikte hem uygulamalar hem de veritabanı için geliştiricilere sahiptir, ancak çoğu geliştirici bu tür ortamlarda çalışmaz. Kodda ellerinden geleni yapıyorlar. Ayrıca, veritabanı tarafındaki bazıları iş kurallarına dahil olmuyor. Öncelikle işleri devam ettirmek için oradalar. Asla db'deki kısıtlamaları zorlamazlar. Eski uygulamalar, entegrasyonlar, göçler, birleşme, devralmalar ile uğraşmak zorunda kalmak bir db kısıtı en iyi çözüm olabilir.
2. Db'nin aşırı yüklenmesi, soruna daha fazla makine fırlatarak kolayca çözülmeyen bir tıkanıklık yaratabilir. Db dilin bazı programlama problemlerini büyük bir performans kaybı olmadan ele almadığı bazı durumlar vardır, bu nedenle her şey için bir kısıtlama kullanmayı planlayamazsınız. Stackoverflow'un bir veritabanı sunucusu vardır, çünkü bir soruna 2 atmak bir zorluktur.
3. Otomatik Test - oraya geliyorlar, ancak birçok db geliştiricisi partiye IDE / test çerçevelerinin yanı sıra geç kaldı.
4. Yerleştirme - daha fazla db öğesi daha karmaşık hale getirir. Kısıtlamayı ihlal eden veriler olduğundan, bir müşterinin veritabanında yapılan bir güncellemeye izin verilmediğinde ne olur? Bunu çözecek bir yolun olmadığı sürece oyun biter. Uygulamanızda, kullanıcının bunu gerektiği şekilde işlemesine izin vermeye karar verebilir veya bazı yöneticilere bunu toplu halde yapmalarını söyleyebilirsiniz.
5. Sadece app / api / service veritabanına veri yazacak, bu yüzden neden rahatsız ettin? Bu çoğu zaman dayanıyor ve bu yüzden yaygın değil.
6. Db hatalarını idare etmek, yüzlerce kısıtlama ihlali olmadan, her şey çarpmaktan çıkarsa başa çıkabilmek için yeterince zordur.

Birçok geliştirme ekibi bir db geliştiricisine çok fazla kontrol vermek istemiyor. Birden fazla alırsanız şanslısınız, bu yüzden tatiller çok eğlenceli. Pek çoğu, veritabanı alanı üzerinde mutlak kontrol gerektirmez ve her sorgu, işletme kuralı, performans, kullanılabilirlik, güvenlik ve hangi verilerin hangi RAID'e gittiğinin sorumluluğunu üstlenir. İşte uygulamanıza izin verilen saklı yordamlar. İyi eğlenceler. Bir masaya dokunmayı bile düşünme.

Bu, tüm kariyerimle (yaklaşık 40 yıl) ve ayrıca DBMS'imi yazarken uğraştığım bir problem. Son noktamın bir açıklaması burada: http://unibase.zenucom.com . İşte benim düşüncelerim.

1. Genel olarak konuşursak, çoğu kısıtlama uygulamada daha iyi ele alınmaktadır, böylece uygulamanın farklı kısımları farklı kısıtlamaları uygulayabilmektedir. örneğin bir devlet kodu tüm yargı bölgelerinde geçerli olmayabilir.
2. Bir kenara% olarak dikkat edin. İşaretlemeler>% 100'dür ya da sen parasızsın :)
3. Kısıtlamalar en iyi şekilde negatif olarak tanımlanır. yani ne olabileceği, olması gerektiği gibi değil. Her zaman daha basit bir liste.
4. Yabancı anahtarlar her zaman iyidir ve kullanılmalıdır. Fullstop. FK, RDBMS'deki az sayıdaki anlamsal yapılardan biridir ve çok kullanışlıdır. En büyük zorluk, FK kaldırılırsa bir değerin sarkmasına izin verilip verilmeyeceği veya bağımlı satırları FK kaydını silmemenin bir nedeni olarak kullanıp kullanmamaya karar vermektir.
5. Gerçek dünyadaki kısıtlamalar, genellikle tek bir alan değeri kısıtlamasından daha karmaşıktır.
6. Bazı kısıtlamalar, uygulama düzeyinde bile, iyi işlemlere karşı çalışır. Örneğin agresif tarih kontrolü, görünüşte iyi tarihlerdeki hataları gizler. Mantıklı görünen tarihlerdeki hataları ölçmek için operatör hatasına ihtiyacınız vardır.

Veritabanı kısıtlamaları akıllıca bir fikir olabilirdi, peki ya onlar için pratik bir kullanım ne olacak? Yüzde kısıtlamanızı alın. Bunu uygularsanız, DB'niz geçersiz yüzdeleri reddeder. Ve sonra? İstisnayı ele almak için iş mantığına ihtiyacınız olacak. Bu aslında, iş mantığının yanlış bir yüzde yazmasının başka bir yerde başarısız olduğu anlamına gelir. Kısacası: geriye kalan tek pratik kısıtlama, gördüğünüz şeyler (PK / FK gibi).

Bugünlerde daha sık, insanlar otomatik olarak tablolar ve sütunlar oluşturmak için yazılımı (örneğin Varlık Çerçevesi) kullanıyor. Fikir, beyin kapasitelerini serbest bırakarak SQL becerilerine ihtiyaç duymamalarıdır.

Yazılımın “işleri çözeceği” beklentileri çoğu zaman gerçekçi değildir ve bir insanın yapabileceği kısıtlamaları yaratmaz.

En iyi sonuçları elde etmek için SQL kullanarak tablolar oluşturun ve kısıtlamaları el ile ekleyin, ancak bazen insanlar bunu yapamaz.