Uygulama mantığına karşı veya veritabanı katmanına yerleştirmenin argümanları nelerdir? [kapalı]

Çoğu yazılım geliştirici, uygulama mantığını uygulama katmanında tutmak ister ve burada tutmamız bizim için büyük olasılıkla doğaldır. Veritabanı geliştiricileri, uygulama mantığını tetikleyiciler ve saklı yordamlar olarak veritabanı katmanına koymak istiyor gibi görünmektedir.

Şahsen, katmanların sorumluluklarını ayıklamayı ve sorumluluklarını ayrı tutmayı kolaylaştırmak için uygulama katmanında mümkün olduğunca tutmayı tercih ederim.

Bu konudaki düşünceleriniz neler ve veri tabanı katmanında uygulamak için ne uygun olmalı veya ne olmamalıdır?

Düzenle Bu soru, DBA'ların bakış açısından dba.se adresinde de ele alınmıştır . Programmers.se & dba.se farklı izleyicilere ve önyargılara sahip olduklarından, gelecek okuyucular onlar için en iyi olanı seçmeden önce her iki cevap grubunu da gözden geçirmek isteyebilirler.

Kafamın üstünden, uygulama katmanına mantık koymanın avantajları .

1. Test edilebilirlik . Bu aslında kendi başına yeterli bir sebep olmalı.
2. Daha iyi kod yapısı . SQL ile doğru OO mimarisini takip etmek çok zor. Bu genellikle aynı zamanda kodun bakımını kolaylaştırır.
3. Kodlaması daha kolay . Hangi dilde kullandığınız farklı dil özellikleri sayesinde uygulama katmanında kodlanması genellikle daha kolaydır.
4. Kod tekrar kullanın . Kodları kütüphanelerle paylaşmak, veritabanındaki kodları paylaşmaktan çok daha kolaydır.

Sürüm kontrolünü saklı yordamlarla (örneğin Redgate veritabanı araçları TFS ile tümleşik olarak) kullanmak mümkün olsa da, uygulama kodunda olduğu gibi her zaman bu kadar kolay değildir.

Benim varsayılan konum, mantığın veritabanı katmanından uzak tutulması gerektiği, ancak mantığın veritabanında uygulanmasının daha verimli olacağı zamanlar vardır. Bu durumda, bu koddaki değişiklikleri izleyebileceğinizden emin olmalısınız.

Çalıştığım bir şirkette, prodüksiyona kod bırakma ve bir kod bırakma için DBA'nın dahil edilmesiyle ilgili çok fazla bürokrasi vardı, her zaman bir kabustu. Çalışması zor olan DBA'larla uğraşmak zorunda kalmamak için her zaman mantığı uygulama katmanına koyarız. Tamamen ahlaksız bir sebep, ancak bir gereklilikten türemiş.

Uygulama mantığını DB'ye koymak bana kötü bir fikir gibi geliyor. Özellikle DB durumunu korumanın bir parçası olan OTOH (“normalize edilmemiş tabloları güncellemek için tetikleyiciler / sprocs)” mantığı koyarak çok farklı bir önermedir.

Alternatif olarak, bu şöyle ifade edilebilir: Veritabanının veri tabanına gerçekten nasıl baktığını görmek için gerekli mantığı ortaya koymak için gerekli mantığı koymak için iyi argümanlar vardır.

Her iki soruyu da okuduktan sonra, hepimizin bir kritik noktayı kaçıracağımızı düşünüyorum. Doğru cevap, geliştirdiğiniz yazılımın türüne bağlı olabilir. DBA grubu büyük ölçüde iş açısından kritik Kurumsal yazılım sistemleri üzerinde çalışmaya meyillidir ve cevapları o dünyada neyin gerekli olduğunu yansıtmaya meyillidir. Bu tür uygulamalar için neyin gerekli olduğuna, bir sonraki "Facebook" uygulaması için gerekenden daha büyük bir fark var. Bir kaç duvar yazısı kaybederseniz, bu bir kaç emir veya başka bir finansal işlemi kaybetmenizdir.

COTS (raflar arası ticari) dünyasında çalışan insanlar, satış nedenleriyle veritabanı için agnostik olma eğilimindedir ve uyumluluk kodundaki herşeyi tersine çevirmeyi ve ürünlerini ev yapımı bir ürünle değiştirmeyi zorlaştırmak isterler. Şirket içinde geliştirilen ve sürdürülen Enterprise uygulamalarının, yükseltme dışında hiçbir zaman veritabanı arka uçlarını değiştirmesi gerekmez.

Kurumsal uygulamalar aynı zamanda birçok yerden veri girişi yapma eğiliminde olanlardır. Çalıştığım sistem, yüzlerce müşteri verisi ithalatı, müşterilere ve veri ambarlarına veri ihracatı ve çoklu raporlama sistemlerini kullanan yüzlerce farklı uygulamaya sahiptir. Bir kayıt eklerken iyi çalışan kod, 20.000.000'i içe aktarmam gerektiğinde başarısız oluyor. Uygulama katmanını bir kez kullanmaya zorlandık çünkü mantığın olduğu yerdi ve işlemi 18 saat sonra bitirmek zorunda kaldık. Bir tablodaki tüm veri kayıtlarına uygulanacak mantığın, herkesin kullandığı bir veri katmanına sahip olamadığınızda veritabanında olması gerekir.

Bunun tersine, yalnızca bir uygulama verileri kullandığında ve veriler şirketinizin can damarı olmadığında veya çok büyük olduğunda, kurallar farklıdır ve tüm mantığı uygulamaya koymak daha mantıklı olur.

Uzunca. altta Özet bölümüne bakın.

RDBMS

Bir RDBMS ilişkisel veritabanı yönetim sistemi anlamına gelir. İlişkisel bir veri tabanını yöneten bir sistemdir. Veri orada saklanır. Veri. İş mantığı demiyor.

İş süreci

İş mantığı gerçekten ne anlama geliyor? Bana göre iş süreçlerini mantıksal olarak açıklıyor.

Süreçler, düzenli olmamakla birlikte, artık geçici olmamaları için yeterli olan ticari faaliyetlerdir. Bunlar her işletme için farklı.

İş başlığımı giyip burada işin ne anlama geldiğini açıklayayım. Bazıları için bu sürpriz olabilir.

iş

İşletme, değerin ve daha özel olarak alınıp satılabilecek değerin yaratılması için gerçekleştirilen faaliyetlerin toplamıdır. Bu, biçerdöverler, ton balıklı sandviçler yapmak veya bankacılık hizmetleri sunmak anlamına gelebilir. Dünya ülkelerinin çoğunda, kapitalist olmayan sistemlerde bile, insanlar paraları için en yüksek değeri elde etmeyi severler ve bu nedenle bu değerli mal ve hizmetlerin farklı tedarikçileri arasında rekabet vardır. Rekabet genellikle fiyat, kalite ve bulunabilirliğe dayanır.

Hızlı yol: 2 günde 40 milyon perçine ihtiyacınız var, fiyatı normal satıcınızın fiyatından ne kadar ucuz olursa olsun, internetteki bir adamdan paypal hesabı olan bir sipariş vermeyeceksiniz.

Süreç Bilgisi

Tahmin edebileceğiniz gibi, bu "değer" in yapılmasına dahil olan süreçler çoğunlukla icra başkanlarında yaşar. Bunların bir kısmı kağıda dökülmüş ve şirket politikaları ve prosedürleri olarak kullanılmıştır. Bunlardan bazıları kurumsal danışmanların başında yaşar. Bunların çoğu, bölümleri, departmanları, ekipleri ve makineleri çalıştıranların kafasında, yazar kasalarda, fırınlarda, kamyonlarda yaşıyor. Bunun küçük bir alt kümesi, yazılımın iş gereksinimlerini aşağılar ve bunun daha küçük bir alt kümesi, bilgisayar sistemlerinde uygulandığı zaman kesindir.

Sonunda, kodda gördüğünüz iş mantığı, bir işletmeyi çalıştıran değil, işletmeyi oluşturan uygulamayı çalıştıran şeydir. Gerçek insanların içindeki gerçek beyinler gerçek iş süreçlerini tutar ve beynindeki işlemlerin bilgisayardaki işlemlerden daha doğru olduğunu anlamada problemleri yoktur. Bir kenara, eğer sahip olduğunuz tek şey çoğu şirketin politika ve prosedürleri olsaydı, muhtemelen işi yürütemezsiniz. Çok sık bunlar, herculian çabalarına rağmen, fena halde yanlış.

Sonuçta, yazılıma kodlanan uygulama mantığı. Ve insanlar bunu veritabanına koymak istiyor, çünkü veritabanı yönetim sistemi satıcıları görkemli iddialarda bulundu.

Uygulama Mantığı

Hayır diyorum. Uygulama mantığı uygulamanın içinde kalıyor diyorum. Veriler çok normalize bir şekilde veri tabanına giriyor ve ETL’yi raporlama ve delme ve toplama ve dönme ve küpleme için veri deposuna alıyor.

Veri

Ayrıca, verilerin uygulamayı dışta bıraktığını da söylüyorum, bu nedenle veri normalleştirme çabası uygulamaya özgü olmamalı ve işletmeye özgü olmamalı, aksine genel olarak ticari olmalıdır. Devlet kodlarını saklıyor musunuz? İşletmeler arasında taşınabilir olduğu için INCITS 38: 2009 (http://www.census.gov/geo/www/ansi/statetables.html) kullanmanız gerekir. Bu aynı zamanda birden fazla uygulamanın verileri değiştirmesini kolaylaştırır.

NoSQL?

Veritabanını uygulamanın kodunun bir parçası olarak, tablo düzeninden tetikleyicilere, saklı yordamlara ve veri biçimlerine kadar ele alırsanız, kurumsal veritabanını esas olarak, yüceltilmiş bir düz dosya yapısı olan yüceltilmiş bir BerkleyDB olarak kullanıyorsunuzdur, Bu gerçekten sadece ısrarlı listeler. Temel olarak NoSQL'in yaptığı şey bu: köklere geri dönmek, fakat bunu çok işlemli, ısrarcı, hataya dayanıklı bir şekilde yapmak.

Gerçek kod

Hayır, veri tabanını mevcut ve gelecekteki birden fazla uygulama için verilerin ortak bir veri deposu olarak görmeniz gerekir. Şimdi argümanımın zirvesine geliyoruz. İş süreçleri pazarın, politikanın ve modanın değişmezleriyle değişiyor. Çoğu zaman, bilgisayar bilimi sınıfı dillerle (Java, C #, C ++ vb.) Kodlayıcıların yönetebildiklerinden daha hızlı değişir ve sonuçta muhasebe veya pazarlama departmanındaki excel elektronik tablolarda VBA'da yazılır. (Ve sadece süslü bakış açılarıyla ifade edilemezse ...)

Veritabanı Bozulması

İyi organize edilmişse, veriler fazla değişmez. İş mantığı çok hızlı değişiyor. İş mantığını veritabanına koyarak, veritabanını daha az değerli hale getirirsiniz, çünkü eskimiş ve yanlış olur.

özet

İş süreçleri uygulamada yaşar ve iş süreçleri çok daha sık değiştiği için veriler uygulamayı aşar. İş mantığını veritabanına dahil etmek, uzun ömürlülüğü ve toplam değeri için kötüdür.

Uyarı

Dbaing'deki payımı yaptım ve cevapları dba.se'de okudum, ama dürüst olmak gerekirse, konuştukları şey veri bütünlüğü sorunları ve performans sorunları. Kurumsal verilere dokunan kişilerin ne yaptıklarını, dba veya programcı veya SAS kıdemli analistin okuma / yazma erişimine sahip olup olmadığını bilmeleri gerektiğine tamamen katılıyorum.

Ayrıca kodlayıcıların SQL bilmelerini önerdiklerini de belirttim. Katılıyorum. Bu bir bilgisayar programlama dili, bu yüzden bilgisayar programcılarının neden bilmek istemediklerini anlamıyorum.

Daha sonra, düşündükten sonra

Bence ana amaç bir API yapmak ve bu API'nin veri akışını yönetmesini sağlamak. Uygulamaların doğrudan tablolara bağlanmasına izin veremiyorsanız, en azından erişim mekanizmasının modern dillerde olmasını sağlayabilirsiniz.

Dramatik ses çıkması riski altında , veritabanındaki uygulama mantığı fikri yüzünden gerçekten dehşete düşüyorum . Buradaki birçok cevap, yazılım geliştirme avantajlarına odaklanmıştır, bu nedenle kısalık adına, sorumluluk bölümünün getirdiği avantajlara odaklanıyorum.

Veritabanları, gereksiz verileri en aza indirirken ve verilerde mantıksal ilişkiler oluştururken, bilgileri depolamak ve erişmek için etkili bir yol sağlar. Veri tabanı mantığı, üretim düzeyi işletme mantığı uygulayabiliyor olsa da, benim kişisel görüşüm, veri tabanının güçlü yönlerine oynarken verilerin birden fazla uygulama tarafından etkin bir şekilde kullanılmasını sağlamak için veri tabanının mümkün olduğu kadar uygulama açısından etkin olması gerektiği yönündedir. Motor, uygulamanın uygulama dilinin güçlü yönlerine karşı.

DBA yığın borsasında bir kullanıcı bunu belirtti ...

Tüm kullanıcılara ve veritabanındaki tüm uygulamalara uygulanacak tüm mantığı istiyorum. Bunu koyacak tek akıllıca yer orası.

En son çalıştığım Fortune 500, OLTP veritabanlarına isabet eden en az 25 dilde yazılı başvuruda bulundu. Bu programlardan bazıları 1970'lerde üretime geçti.

... Bunun, KURU ilkesinin ihlal edildiğinin bir göstergesi olduğu inancıyla takip edildi.

İş mantığının tekrarı olmaktan ziyade, bunun iş katmanı ile veri katmanı arasındaki ayrı bir sorumluluk dağılımı tarafından sağlanan esnekliğin mükemmel bir örneği olduğunu düşünüyorum.

OLTB veritabanları, on yıllardır 25+ uygulamaya güvenilir ve verimli bir şekilde veri sağlıyor! Bu harika! (Gitme zamanı!)

Verilerin yalnızca birkaç farklı uygulama için içerik sağlayacak kadar agnostik olduğunu varsayabilirim. Bu geliştiriciler veritabanı mantığını kullanarak bir şeyi bir araya getirmeye çalışırlarsa büyük ölçüde imkansız olan bir şey.

Diğer cevapların belirttiği gibi, bir programı veritabanında uygulamamak için birçok neden vardır . İşe yarayacağından eminim, ancak en muhtemel sonuç, onlarca yıl süren istikrardan ziyade onlarca pişmanlık olacaktır.

Veritabanı agnostik uygulamaları veritabanlarının tüm mantığını gerektirir. Pek çok farklı veritabanı sağlayıcısının kodunu oluşturmak ve korumak çok zor.

İyi bir gelişme, mantığın bir kısmını veritabanında ve uygulamada da uygulayarak veritabanı bütünlüğü ihtiyacı ile hız arasında iyi bir denge kuracaktır.

Aynı sorgu birçok uygulamada tekrar tekrar kullanılacak mı, o zaman belki saklı bir prosedüre ait olabilir.

Satır yerleştirme ve güncelleme sırasında ev tutma alanlarının ayarlandığından emin olmak bir DBA sorumluluğudur. Bir tetikleyici kullanılacaktır.

Öte yandan, eğer iş mantığım varsa uygulamada olması gerekiyor. Mümkün olduğunda, istenen tam alan miktarıyla ayarlanan istenen, filtrelenmiş kaydı geri döndürecek olan saklı yordamlara çağrı yapılmalıdır. Daha fazla değil, daha az değil.

Takımlar arasındaki iletişim meselesi ve her olasılık için artıları ve eksileri tanıma meselesi.

Benim düşüncem: Uygulama mantığını DB'de çok derin yapmayın.

Bazı alım satım sistemleri, mevcut veritabanını temelde veritabanına yazılan komut dosyaları ile genişletmenin bir yolunu sunar. Bununla ilgili deneyimim, en azından çok kullanıcılı bir ortamda oldukça olumsuz.

Mantığı bir veritabanına koyarsınız, çünkü bu mantığı kolayca değiştirebilmek istersiniz.

• Sürüm kontrolünü nasıl yaparsınız?
  • Kod geçmişi nedir? Değişiklikler neydi? Kim tarafından?
  • Aynı kod parçasındaki değişiklikleri nasıl halledersiniz?
• Tutarlı bir kod durumunu nasıl belirler ve garanti ederdiniz?

Bunu dosya tabanlı ek bir VCS'de takip edebilirsiniz, ancak daha sonra veritabanının faydası nedir?

Çoğu uygulamanın entegrasyonu sağlamak için bir yol olması gerekir. İdeal olarak, tam bir API'ye, bir web servisine veya en azından işletme mantığını içeren bazı veritabanı nesnelerine sahip olmanız gerekir. Bir API oluşturmak için herkes zaman / kaynak konumunda değildir, bu nedenle ödün vermek zorundasınız.