Veritabanındaki tablolar arasında veya sadece koddaki ilişkileri tanımlamalı mıyım?

Tecrübelerime göre, geçmişte okuduğum birçok projenin veritabanında ilişki tanımları yoktu, sadece kaynak kodunda tanımladılar. Bu yüzden veritabanındaki tablolar ile kaynak kod arasındaki ilişkileri tanımlamanın avantajları / dezavantajları nelerdir? Ve daha geniş olan soru, çağlayan, tetikleyiciler, prosedürler gibi modern veritabanlarındaki diğer gelişmiş özellikler hakkında… Düşüncelerimde bazı noktalar var:

Veritabanında:

• Tasarımdan doğru veriler. Geçersiz veriye neden olabilecek uygulama hatalarını önleyin.

• Uygulama veri toplama bütünlüğünü kontrol etmek için daha fazla sorgu yapmak zorunda olduğu için veri eklerken / güncellerken uygulamaya gidiş dönüş ağını azaltın.

Kaynak kodda:

• Daha esnek.

• Birden çok veritabanına ölçeklenirken daha iyi, bazen ilişki çapraz veritabanı olabilir.

• Veri bütünlüğü üzerinde daha fazla kontrol. Veritabanının, uygulama verileri her değiştirdiğinde kontrol etmesi gerekmez (karmaşıklık O (n) veya O (n log n) (?) Olabilir). Bunun yerine, başvuru için yetkilendirildi. Ve uygulamada veri bütünlüğünün ele alınmasının veritabanını kullanmaktan daha ayrıntılı hata mesajlarına yol açacağını düşünüyorum. Örn: bir API sunucusu oluşturduğunuzda, veritabanındaki ilişkileri tanımlarsanız ve bir şeyler ters giderse (başvurulan varlık olmadığı gibi), bir mesajla birlikte bir SQL İstisnası alırsınız. En basit yol, müşteriye "Dahili sunucu hatası" olduğunu ve müşterinin neyin yanlış gittiğini bilmemesidir. Veya sunucu, neyin yanlış olduğunu bulmak için mesajı çözümleyebilir, bu bence çirkin, hataya açık bir yoldur. Uygulamanın bunu yapmasına izin verirseniz,

Başka bir şey var mı?

Düzenleme: Kilian'ın işaret ettiği gibi, performans ve veri bütünlüğü konusundaki noktam çok yanlış yönlendirilmiş. Bu yüzden oradaki amacımı düzeltmek için düzenleme yaptım. Veritabanını işlemesine izin vermenin daha verimli ve sağlam bir yaklaşım olacağını tamamen anladım. Lütfen güncellenmiş soruyu kontrol edin ve bu konuda bazı düşünceler verin.

Düzenleme: herkese teşekkürler. Aldığım cevaplar, kısıtlamaların / ilişkilerin veritabanında tanımlanması gerektiğine işaret ediyor. :). Bir sorum daha var, bu sorunun kapsamı dışında olduğu için, ayrı bir soru olarak gönderdim: API sunucusu için veritabanı hatası işleyin . Lütfen bazı görüşlerinizi bırakın.

TL; DR: İlişki kısıtlamaları veritabanında yer almalıdır.

Başvurunuz yeterince büyük değil.

Sen veritabanları arasında zorlama ilişkiler olduğunu, gerçekten, doğru olabilir uygulamada bunların uygulanmasında gerektirir.

Bununla birlikte, öncelikle, kullandığınız veritabanı yazılımının belgelerini ve mevcut ürün tekliflerini kontrol etmelisiniz. Örneğin, Postgres ve MySQL'in üzerine kümelenme teklifleri var.

Uygulamada bazı onaylamalar yapmanız gerekse bile , bebeği banyo suyuyla atmayın . Sonuçta, ne kadar az yapmak zorunda kalırsanız, o kadar iyi olursunuz.

Son olarak, gelecekteki ölçeklenebilirlik konularında endişeleniyorsanız, başvurunuzun yine de ölçeklenebilmesi için önemli değişikliklere uğraması gerekeceğinden korkuyorum. Genel bir kural olarak, her 10 kez büyüdüğünüzde, yeniden tasarlamanız gerekir ... bu yüzden ölçeklenebilirlik sorunlarını önceden tahmin etmemek için çok fazla para biriktirmeyelim ve bunun yerine bu sorunların olduğu noktaya ulaşmak için parayı kullanmayalım.

Başvurunuz yeterince doğru değil.

Kullandığınız veritabanının , uygulamanın hatalı bir şekilde uygulanması olasılığına sahip olma olasılığına kıyasla hatalı bir onay uygulaması olması ihtimali nedir?

Hangisini en sık değiştiriyorsunuz?

Her zaman , veritabanının doğru olduğuna bahse girerim .

Geliştiricileriniz yeterince dağıtılmış düşünmüyor.

Uygulama veri toplama bütünlüğünü kontrol etmek için daha fazla sorgu yapmak zorunda olduğu için veri ekle / güncellediğinde ağa gidiş dönüşünü azalt.

Kızıl Bayrak ! ¹

Eğer düşünüyorsan:

• kaydın olup olmadığını kontrol et
• değilse kayıt ekleyin

daha sonra en temel eşzamanlılık sorununda başarısız oldunuz : başka bir işlem / iş parçacığı kaydı ilerledikçe ekliyor olabilir.

Eğer düşünüyorsan:

• kaydın olup olmadığını kontrol et
• değilse kayıt ekleyin
• kaydın kopya olarak eklenip eklenmediğini kontrol edin

o zaman başarısız MVCC hesaba: Sahip olduğunuz veritabanının görünümü işlem başlatıldı anda bir anlık görüntüsüdür; o mu değil meydana gelen ve belki de kararlı olan tüm güncelleştirmeleri gösteriyor.

Birden fazla oturumda kısıtlamaları korumak gerçekten zor bir problem, veritabanında çözüldüğü için memnunum.

¹ Veritabanınız Seri hale getirilebilir özelliği doğru şekilde uygulamazsa; ama çok azı aslında yok.

Son:

Ve bence, uygulamadaki veri bütünlüğünü ele almak, veritabanını kullanmaktan daha ayrıntılı bir hata mesajı verilmesine izin verecektir. Örn: bir API sunucusu oluşturduğunuzda. Veritabanındaki ilişkileri tanımlarsanız ve bir şeyler ters giderse (başvurulan varlık olmadığı gibi), mesajla birlikte bir SQL İstisnası alırsınız.

Hata mesajlarını ayrıştırmayın , herhangi bir üretim sınıfı veritabanı kullanıyorsanız yapılandırılmış hataları döndürmelidir. En azından muhtemelen neyin yanlış olduğunu göstermek için bazı hata kodlarına sahip olacaksınız ve bu koda dayanarak uygun bir hata mesajı oluşturabilirsiniz.

Kodun çoğu zaman yeterli olduğuna dikkat edin: başvurulan bir yabancı anahtarın olmadığını söyleyen bir hata kodunuz varsa, bu tablonun yalnızca bir yabancı anahtarının olması muhtemeldir, bu nedenle kodda sorunun ne olduğunu bilirsiniz. .

Ayrıca, burada dürüst olalım, çoğu zaman zaten zarafetle yapılan hataları ele almayacaksınız. Sırf o kadar çok kişi var ki ve hepsini hesaba katamazsın ...

... sadece yukarıdaki doğruluk noktasına bağlıyor. Bir veritabanı kısıtlaması başlatıldığından ve işlendiğinden her zaman "500: Dahili Sunucu Hatası" görüyorsanız, kodda işlemeyi unuttuğunuzdan, veritabanı sizi kurtardı demektir.

Uygulama verileri her değiştirdiğinde veritabanının veri bütünlüğünü kontrol etmesi gerekmez.

Bu çok yanlış yönlendirilmiş bir nokta. Veritabanları tam da bu amaç için oluşturulmuştur. Veri bütünlüğü kontrollerine ihtiyacınız varsa (ve onlara ihtiyaç duymadığınızı düşünüyorsanız, muhtemelen yanılıyorsunuzdur), o zaman veritabanının bunları ele almasına izin vermek uygulama mantığında olduğundan çok daha etkili ve daha az hataya açıktır.

(Dünyanın en iyi irade ile), başvurunuz gibi kısıtlamalar, veritabanı içinde durmalıdır değil hiç bu veritabanına erişim tek şey.

Bir noktada, veritabanında kodlu bir düzeltme yapılması gerekebilir veya dağıtımda verileri bir tablodan diğerine geçirmeniz gerekebilir.

Ek olarak, örneğin "Büyük müşteri X'in gerçekten bu öğleden sonra uygulama veritabanımıza aktarılan bu mükemmel veri sayfasına ihtiyacı var" gibi başka gereksinimler de alabilirsiniz. zamanında.

Bu, veritabanı düzeyinde bütünlüğün pastırmanızı koruyacağı yerdir.

Ek olarak, ayrıldıktan sonra bu şirkette rolünüzü alan geliştiriciyi hayal edin ve ardından veritabanı değişiklikleri yapmakla görevlendirin.

Veritabanında FK kısıtlamaları yoksa, tablonun değiştirmeden önce hangi ilişkileri olduğunu söyleyebilmesi için sizden nefret edecek mi? ( İpucu, cevap evet )

Veritabanında ilişkilerin olmalı.

Diğer cevabın belirttiği gibi, kısıt kontrolünün performansı bu veritabanında uygulamanızın içinde olduğundan çok daha iyi olacaktır. Veritabanı kısıtlamaları kontrolleri veritabanlarının iyi olduğu şeylerden biridir.

Ek esnekliğe ihtiyacınız varsa - örneğin, belirtilen çapraz veritabanı referanslarınız - o zaman kısıtlamaları kasten ve düşünerek kaldırabilirsiniz. Veritabanınızda tutarlılık olması, bu kısıtlamaları ve referans bütünlüğünün kesinliğini değiştirme seçeneğiniz olduğu anlamına gelir.

• Artık bir arka uç <-> bir ön uç dünyada yaşamıyoruz.
• Çoğu çözüm bir web ön ucu, mobil ön uç, toplu ön uç ve iPad ön ucu vb.
• Veritabanı motorları zaten referans bütünlüğünü zorlamak için optimize edilmiş binlerce kod satırına sahiptir.

Alan yazmakta sorun çözme probleminiz olduğunda referans bütünlüğü zorlama kodunu gerçekten yazıp test edebilir misiniz?

Veri bütünlüğünüzü, kısıtlamalarınızı, ilişkilerinizi vs. veri tabanı düzeyinde doğrulamıyorsanız, üretim veritabanı erişimi olan herkesin (DB erişim aracı da dahil olmak üzere herhangi bir müşteri aracılığıyla) verilerinizi karıştırması çok daha kolaydır.

Veri tabanı seviyesinde mümkün olan en katı veri bütünlüğünü uygulamak harika bir uygulamadır. İnan bana, bu sana önemsiz olmayan bir sistemde zamanla muazzam baş ağrıları kazandıracak. Dikkatli bir şekilde düşünülürse uygulama mantığı hatalarını veya iş gereksinimi hatalarını ve tutarsızlıkları daha hızlı toparlayacaksınız.

Buna bir not olarak, veritabanınızı mümkün olduğunca normal ve atomik şekilde tasarlayın. "Tanrı" masası yok. Veritabanınızı mümkün olduğu kadar basit olacak şekilde, ideal olarak ayrı ayrı çok iyi tanımlanmış, tek bir sorumlulukla ve tüm sütunlarda dikkatlice doğrulanmış birçok küçük tablo için tasarlayarak çok çaba harcayın. Veri tabanı, veri bütünlüğünüzün son koruyucusudur. Kalenin Tutma'yı temsil eder.

Çoğu insan aslında "evet genel olarak söylediğini -eceksin daima veritabanında ilişkileri tanımlamak". Ancak bilgisayar bilimindeki disiplinler çok kolay olsaydı, "Yazılım Mühendisleri" yerine "Yazılım El Kitabı Okuyucular" olarak adlandırılırdık. Aslında, kısıtlamaların veritabanına girmesi gerektiğine katılıyorum, yapmamaları için iyi bir neden olmadıkça , bazı durumlarda iyi olarak kabul edilebilecek birkaç neden belirteyim:

Yinelenen Kod

Bazen veritabanı tarafından ele alınabilecek belirli bir işlevsellik doğal olarak uygulama kodunda mevcut olabilir. Veritabanına kısıtlamalar gibi bir şey eklemek gereksiz olabilirse, DRY ilkelerini ihlal ettiğinizden ve veritabanını ve uygulama kodunu senkronize tutma konusundaki hokkabazlık eylemini daha da kötüleştireceğiniz için işlevselliği çoğaltmamak daha iyi olabilir.

Çaba

Veritabanınız zaten gelişmiş özellikleri kullanmadan yapması gereken şeyi yapıyorsa, zamanınızın, paranızın ve çabanızın nereye yerleştirileceğini değerlendirmek isteyebilirsiniz. Kısıtlamalar eklemek feci bir başarısızlığı önlerse ve böylece şirketinize çok para kazandırırsa, buna değer. Tutması gereken ancak zaten ihlal edilmemesi garantili olan kısıtlamalar ekliyorsanız, zaman harcıyor ve kod tabanınızı kirletiyorsunuz. Buradaki işlemsel kelime garanti .

verim

Bu normalde iyi bir neden değildir, ancak bazı durumlarda belirli bir performans gereksiniminiz olabilir. Uygulama kodu, belirli bir işlevi veritabanından daha hızlı bir şekilde uygulayabilir ve ekstra performansa ihtiyacınız varsa, özelliği uygulama kodunda uygulamanız gerekebilir.

Kontrol

Verimlilik ile ilgili biraz. Bazen bir özelliğin nasıl uygulandığına dair son derece hassas kontrole gereksiniminiz olur ve bazen veritabanının işlemesi onu açmanız gereken kara bir kutunun arkasına gizler.

Kapanış Noktaları

• Veritabanları kodda yazılmıştır. Kendi kodunuzda yapamayacağınız sihirli bir şey yok.
• Hiçbir şey bedava değil. Kısıtlamalar, ilişkiler vb. Hepsi CPU çevrimlerini kullanır.
• NoSQL dünyasındaki insanlar geleneksel İlişkisel özellikler olmadan gayet iyi geçinirler. Örneğin, MongoDB'de JSON belgelerinin yapısı tüm veritabanını destekleyecek kadar iyidir.
• Gelişmiş veritabanı özelliklerinin kör ve cahil kullanımı herhangi bir yararı garanti edemez. Yanlışlıkla bir şeyi daha sonra kırmak için işe yaratabilirsiniz.
• Belirli gereksinimleri veya kısıtlamaları listelemeden çok genel bir soru sordunuz. Sorunuza asıl cevap "bağlıdır".
• Bunun kurumsal ölçekli bir sorun olup olmadığını belirtmediniz. Diğer cevaplar müşteriler ve veri bütünlüğü gibi şeylerden bahsediyor, ama bazen bu önemli değil.
• Geleneksel bir SQL İlişkisel veritabanı hakkında konuştuğunuzu farz ediyorum.
• Benim bakış açım, küçük (50 tabloya kadar) projelerde tonlarca kısıtlama ve yabancı anahtar kullanmaktan uzaklaşmaktan ve dezavantajları fark etmekten geliyor .

Söyleyeceğim son şey, işlevselliği veritabanına yerleştirmemeniz gerekip gerekmediğini bilmenizdir. Emin değilseniz, veritabanı özelliklerini kullanmakta muhtemelen daha iyi olursunuz, çünkü genellikle iyi çalışırlar.

Her zaman olduğu gibi, birçok cevap var. Benim için basit bir kural buldum (peki sadece model merkezli bir yaklaşım için işe yarıyor). Genellikle, sadece farklı uygulama katmanlarına odaklanırım.

Model birkaç varlıktan oluşuyorsa ve varlıklar arasında bağımlılıklar varsa, kalıcılık katmanı bu bağımlılıkları olanaklarıyla yansıtmalıdır. Eğer bir RDBMS kullanıyorsanız, yabancı anahtarları da kullanmalısınız. Sebep basittir. Bu şekilde veriler her zaman geçerli yapısaldır.

Bu kalıcılık katmanı üzerinde çalışan herhangi bir örnek buna güvenebilir. Bu katmanı arabirim (hizmet) ile kapladığınızı farz ediyorum. İşte tasarımın bittiği ve gerçek dünyanın başladığı nokta.

Noktalarınıza bakarken, özellikle çapraz veritabanı referansları . Bu durumda, evet, RDBMS'nin kendisinde uygulanmış bir referans olmamalıdır, ancak hizmette. Ancak bu yolu izlemeden önce, tasarım sırasında zaten bunu düşünmek daha iyi olmaz mıydı?

Zaten bilirsem, farklı bir DB'de saklanması gereken parçalar olduğunu gösterir, o zaman onları zaten oraya koyabilir ve ayrı bir model olarak tanımlayabilirim. Sağ?

Ayrıca, bunu kodda uygulamanın daha esnek olduğunu belirtiyorsunuz . Doğru, ama eksik bir tasarımla uğraşıyormuşsun gibi gelmiyor mu? Kendinize sorun, neden daha fazla esnekliğe ihtiyacınız var?

DB'deki bütünlük kontrolleri nedeniyle performans sorunu gerçek değil. RDBMS, bu tür şeyleri sizin tarafınızdan yapılan uygulamalardan çok daha hızlı kontrol edebilir. Neden? RDBMS, medya bozulmalarıyla başa çıkmak zorunda. Ve bu gibi kontrolleri aso istatistiklerini kullanarak optimize edebilir.

Yani görüyorsunuz, her şey yeniden tasarıma dönüyor. Tabii ki şimdi söyleyebilirsiniz, ama ne bilinmeyen bir gereklilik ortaya çıkıyorsa, bir oyun değiştirici? Evet olabilir, ancak böyle değişiklikler de tasarlanmalı ve planlanmalıdır. ;Ö)

Çok iyi cevapların var ama biraz daha puanın var.

Veri bütünlüğü, bir veritabanı yapmak için tasarlandığı şeydir.

Uygulama düzeyinde bir FK silme gibi uygun eşzamanlılık yapılması korkunç olacaktır.

Veri bütünlüğündeki uzmanlık DBA ile birlikte

Girdiğiniz program düzeyinde güncelleme, toplu güncelleme, toplu ekleme, toplu silme ...
İnce istemci, kalın istemci, mobil istemci ....
Veri bütünlüğü bir programcının uzmanlığı değildir - birçok yinelenen kod ve birileri karışır o kadar

Korsanlığa uğradığınızı söyleyin - her iki durumda da başınız dertte ama veritabanında bütünlük koruması yoksa korsan çok küçük bir delikten çok fazla zarar verebilir

Verileri doğrudan SQL veya TSQL üzerinden yönlendirmeniz gerekebilir
Hiç kimse tüm veri kurallarını hatırlamayacak

Sorunuz bir anlam ifade etmiyor: veritabanını değiştirebiliyorsanız, kodudur, veritabanını değiştiremiyorsanız, sınırlarınızı başka bir yerde oluşturmanız gerekir.

Değiştirebileceğiniz bir veritabanı her bit, herhangi bir ruby, javascript, c # veya ada satırı kadar koddur.

Sisteminizde kısıtlamayı nereye koyacağınız sorusu güvenilirlik, maliyet ve geliştirme kolaylığı ile sonuçlanmalıdır.

Burada tonlarca iyi cevap var. Y dilinde yazılmış bir uygulamanız varsa, Y'de veritabanı kısıtlaması benzeri bir kod oluşturabildiğinizi ve ardından birisinin Z dilini kullanarak veritabanınıza erişmek istediğini, aynı kodu tekrar yazmanız gerektiğini ekleyeceğim. Eğer uygulamalar tamamen aynı değilse, Tanrı size yardım eder . Bilgili bir işletme kullanıcısı Microsoft Access kullanarak veritabanınıza bağlanırsa.

Deneyimlerim bana, insanlar veritabanı kısıtlamaları kullanmak istemedikleri zaman, bunun aslında yanlış bir şey yapmaya çalıştıkları olduğunu söylüyor. Örneğin, veri yüklemeye çalışıyorlar ve bir süre boş olmayan sütunları boş bırakmak istiyorlar. "Bunu daha sonra düzeltmek" istiyorlar çünkü boş olmayan kısıtlamayı kritik yapan durum "bu durumda olamaz". Başka bir örnek, aynı tabloya iki farklı türde veriyi kornayı çalmaya çalışırken olabilir.

Daha deneyimli insanlar geri adım atar ve bir kısıtlamayı atlamayı denemeyi içermeyen bir çözüm bulur. Çözüm, basitçe kısıtlama olabilirdi, çünkü iş elbette değişti.