Veritabanı ne kadar iş mantığı uygulamalı?

İş mantığının çoğunun veritabanında uygulandığı bazı projelerde çalıştım (çoğunlukla saklı yordamlarla). Diğer taraftan bazı diğer programcılardan bunun kötü bir uygulama olduğunu duydum ("Veri depolamak için veritabanları var. Gerisini orada yapmak için uygulamalar var").

Bu yaklaşımlardan hangisi genel olarak daha iyidir?

DB'de iş mantığını uygulayabileceğimin avantajları:

• İş mantığının merkezileşmesi;
• Uygulama türünün bağımsızlığı, programlama dili, işletim sistemi vb .;
• Veritabanları teknoloji göçüne veya büyük yeniden düzenlemelere (AFAIK) daha az eğilimlidir;
• Uygulama teknolojisi geçişi üzerinde tekrar çalışma yoktur (örneğin: .NET'ten Java'ya, Perl'den Python'a vb.).

Eksiler:

• SQL, daha az üretken ve iş mantığı programlaması için daha az karmaşıktır;
• Daha zor (eğer mümkünse) kod kütüphanelerde tekrar kullanmak;
• Daha az üretken IDE'ler.

Not: Bahsettiğim veritabanları ilişkisel, SQL Server, Oracle, MySql vb. Popüler veritabanlarıdır.

Teşekkürler!

İş mantığı veritabanına girmiyor

Çok katmanlı uygulamalardan bahsediyorsak, belirli bir kuruluşu çalıştıran iş zekası olan iş mantığının Veri Erişim Katmanına değil, İş Mantığı Katmanına ait olduğu açıkça görülüyor.

Veritabanları birkaç şeyi gerçekten iyi yapar:

1. Veri depolar ve alırlar
2. Farklı veri varlıkları arasında ilişkiler kurar ve uygularlar
3. Cevaplar için veri sorgulama aracı sağlarlar
4. Performans iyileştirmeleri sağlarlar.
5. Erişim kontrolü sağlarlar

Şimdi, elbette, işle ilgili kaygılarınız, vergi oranları, indirimler, işlem kodları, kategoriler ve benzeri şeylerle ilgili her türlü şeyi bir veritabanında kodlayabilirsiniz. Ancak, bu verilerle alınan ticari eylem , genellikle başkaları tarafından belirtilen her türlü nedenden ötürü, genellikle veritabanına kodlanmaz, ancak veritabanında bir eylem seçilip başka yerlerde de gerçekleştirilebilir.

Ve elbette, performans ve diğer nedenlerle bir veritabanında gerçekleştirilen şeyler olabilir:

1. Bir hesap dönemi kapatılıyor
2. Sayı çatırtı
3. Gecelik parti işlemleri
4. Fail-over

Doğal olarak, hiçbir şey taşa kazınmamıştır. Saklı yordamlar, yalnızca veritabanı sunucusunda yaşadıkları ve belirli güçlü yönleri ve avantajları olduğu için çok çeşitli görevler için uygundur.

Her Yerde Saklı İşlemler

Tüm veri depolama, yönetim ve alma görevlerinizi saklı yordamlarda kodlamanın ve sonuçta ortaya çıkan veri hizmetlerini tüketmenin kesin bir cazibesi var. Kesinlikle veritabanı sunucusunun sağlayabileceği maksimum performans ve güvenlik optimizasyonundan faydalanabilirsiniz ve bu küçük bir şey değildir.

Ama neyi riske atıyorsun?

1. Satıcı kilidi
2. Özel yetenek setleri olan geliştiricilere duyulan ihtiyaç
3. Spartalı programlama araçları, genel olarak
4. Son derece sıkı yazılım bağlantısı
5. Kaygıların ayrılması yok

Ve tabii ki, eğer bir web servisine ihtiyacınız varsa (ki bu muhtemelen her şeyin başlığıdır), yine de onu inşa etmek zorunda kalacaksınız.

Peki, tipik uygulama nedir?

Tipik ve modern bir yaklaşımın, tablolarınızı modelleyen sınıflar oluşturmak için bir Nesne İlişkisel Eşleştiricisi (Varlık Çerçevesi gibi) kullanmak olduğunu söyleyebilirim. Daha sonra, herhangi bir yetkili yazılım geliştiricisinin çok bildiği bir durum olan nesnelerin koleksiyonlarını döndüren bir depo aracılığıyla veritabanınızla konuşabilirsiniz. ORM, veri modelinize ve istenen veriye karşılık gelen SQL'i oluşturur; bu durumda veritabanı sunucusu, sorgu sonuçlarını döndürmek için işler.

Bu ne kadar iyi çalışıyor? Çok iyi ve saklı yordamlar ve görüşler yazmaktan çok daha hızlı. Bu genellikle veri erişim gereksinimlerinizin yaklaşık% 80'ini, çoğunlukla CRUD'yi kapsar. Diğer% 20 oranı nedir? Bunu tahmin ettiniz: tüm büyük ORM'lerin doğrudan desteklediği saklı prosedürler.

ORM ile aynı şeyi yapan, ancak saklı yordamlar içeren bir kod oluşturucu yazabilir misiniz? Tabi ki yapabilirsin. Ancak ORM'ler genellikle satıcıdan bağımsızdır, herkes tarafından iyi anlaşılır ve daha iyi desteklenir.

İş mantığını mümkün olduğunca veritabanından uzak tutmaya güçlü bir inancım. Ancak, şirketimin performans geliştiricisi olarak bazen iyi performans elde etmek için gerekli olduğunu takdir ediyorum. Ancak bence insanların iddia ettiğinden çok daha az gerekli.

Artılarını ve eksilerini tartışıyorum.

İş mantığınızı merkezileştirdiğini iddia ediyorsunuz. Aksine, bence merkezsizleştiriyor. Şu anda üzerinde çalıştığım bir üründe, iş mantığımızın çoğu için saklı yordam kullanıyoruz. Performans sorunlarımızın çoğu, tekrar tekrar arama işlevlerinden kaynaklanır. Örneğin

select <whatever>
from group g
where fn_invoker_has_access_to_group(g.group_id)

Bu yaklaşımla ilgili sorun, genel olarak (bunun yanlış olduğu durumlar olabilir) veritabanını, işlevinizi satır başına bir kez N kez çalıştırmaya zorlar. Bazen bu fonksiyon pahalıdır. Bazı veritabanları işlev dizinlerini destekler. Ancak, mümkün olan her işlevi olası her girişe göre indeksleyemezsiniz. Yoksa yapabilir misin?

Yukarıdaki soruna ortak bir çözüm, mantığı işlevden çıkarmak ve sorguyla birleştirmektir. Şimdi enkapsülasyonu ve çoğaltılmış mantığı kırdınız.

Gördüğüm bir diğer konu da bir döngüdeki saklı yordamları çağırmak çünkü saklı proc sonuç kümelerine katılmak veya kesişmek mümkün değildir.

declare some_cursor
while some_cursor has rows
    exec some_other_proc
end

Kodu iç içe geçmiş taslaktan çıkarırsanız, yeniden ademi merkeziyetçilikten geçirirsiniz. Bu nedenle, kapsülleme ve performans arasında seçim yapmak zorunda kalırsınız.

Genel olarak, veritabanlarının kötü olduğunu görüyorum:

1. Hesaplama
2. Yineleme (ayar işlemleri için optimize edilmişlerdir)
3. Yük dengeleme
4. ayrıştırma

Veritabanları iyi:

1. Kilitleme ve açma
2. Veri ve ilişkilerini korumak
3. Bütünlüğü sağlamak

Döngüler, ip gibi ayrıştırma gibi pahalı işlemler yaparak bunları uygulamanızın içinde tutarak daha iyi performans elde etmek için başvurunuzu yatay olarak ölçeklendirebilirsiniz. Bir yük dengeleyicisinin arkasına birden fazla uygulama sunucusu eklemek genellikle veritabanı çoğaltmasını ayarlamaktan çok daha ucuzdur.

Ancak, iş mantığınızı uygulamanızın programlama dilinden ayırdığı konusunda haklısınız, ancak bunun neden bir avantaj olduğunu anlamıyorum. Bir Java uygulamanız varsa, bir Java uygulamanız vardır. Bir sürü Java kodunu saklı yordamlara dönüştürmek, bir Java uygulamanızın olduğu gerçeğini değiştirmez.

Tercihim, veritabanı kodunun sebat odaklı olmasını sağlamak. Yeni bir widget'ı nasıl yaratırsınız? 3 tabloya eklemelisiniz ve bir işlemde olmalıdırlar. Bu saklı bir prosedüre aittir.

Bir widget'a neler yapılabileceğini ve bir widget bulmak için iş kurallarının tanımlanması uygulamanıza aittir.

Konuyla ilgili farklı vizyonlara sahip 2 farklı firmada çalıştım.

Kişisel önerim, yürütme zamanı önemli olduğunda (performans) Saklı Prosedürleri kullanmak olacaktır. Saklı Yordam derlendiğinden, verileri sorgulamak için karmaşık bir mantığınız varsa, bunu veritabanında saklamak daha iyidir. Ayrıca, nihai verileri yalnızca sonunda programınıza gönderir.

Aksi takdirde, bir programın mantığının her zaman yazılımın kendisinde olması gerektiğini düşünüyorum. Neden? Çünkü bir programın test edilebilir olması gerekir ve saklanan prosedürü test etmenin kolay bir yolu olduğunu sanmıyorum. Unutma, test edilmemiş bir program kötü bir programdır.

Bu nedenle gerektiğinde Saklı Prosedürü dikkatli kullanın.

Bulmanız gereken bir orta yol var. Programcıların veritabanını overpriced anahtar / değer deposundan başka bir şey olarak kullandıkları korkutucu projeler gördüm. Programcıların yabancı anahtar ve indeksleri kullanmadığı yerlerde başkalarını gördüm. Spektrumun diğer ucunda, çoğu iş mantığının veritabanı kodunda uygulanmadığı projeleri gördüm.

Sizin de belirttiğiniz gibi, T-SQL (veya diğer popüler RDBMS'lerde eşdeğeri), karmaşık iş mantığını kodlamak için tam olarak en iyi yer değil.

Makul bir veri modeli oluşturmaya çalışıyorum, veri tabanının özelliklerini, bu model hakkındaki varsayımlarımı korumak için kullanıyorum (yani, FK'ler ve kısıtlamalar) ve veritabanı kodunu az kullanıyorum. Veri tabanı kodu, veri tabanının çok iyi olduğu bir şey (yani toplam) gerektiğinde kullanışlıdır ve ihtiyaç duymadığınız zamanlarda bir zilyon kaydını tel üzerinde taşımaktan kurtarır.

İş mantığınız ayarlanmış işlemleri içeriyorsa, bunun için iyi bir yer veritabanındadır, çünkü veritabanı sistemleri ayarlanmış işlemleri gerçekleştirmede gerçekten iyidir.

http://en.wikipedia.org/wiki/Set_operations_(SQL)

İş mantığı bir tür hesaplama içeriyorsa, veritabanları gerçekten döngü ve hesaplama için tasarlanmadığından büyük olasılıkla veritabanı / mağaza prosedürünün dışındadır.

Bunlar zor ve hızlı kurallar olmasa da, iyi bir başlangıç ​​noktasıdır.

Buna doğru bir cevap yok. Veritabanını ne için kullandığınıza bağlıdır. Bir kurumsal uygulamada, veritabanındaki mantığa yabancı anahtarlar, kısıtlamalar, tetikleyiciler vb. Yoluyla ihtiyacınız vardır, çünkü tüm olası uygulamaların kodu paylaştığı tek yer burasıdır. Ayrıca, gerekli mantığı koda koymak genellikle veri tabanının tutarsız olduğu ve verilerin kalitesiz olduğu anlamına gelir. Bu, yalnızca GUI'nin nasıl çalıştığı ile uyumlu olan bir uygulama geliştiricisine önemsiz görünebilir, ancak verileri uygunluk raporlarında kullanmaya çalışan kişilerin, milyarlarca dolar para cezası aldıklarında, çok can sıkıcı ve maliyetli bulduklarını temin ederim. kuralları doğru takip etmeyin.

Düzenleyici olmayan bir ortamda, tüm kayıt kümesini çok fazla umursamadığınızda ve yalnızca bir veya iki uygulama veritabanına çarptığında, belki de hepsini uygulamada saklamaktan kurtulabilirsiniz.

Birkaç yıl sonra, soru hala önemli ...

Benim için basit bir kural: mantıksal bir kısıtlama veya her yerde bulunan bir ifade (tek ifade) ise onu veritabanına yerleştirin (evet, yabancı anahtarlar ve kontrol kısıtlamaları da iş mantığıdır!). Prosedürel ise, döngüler ve koşullu dallar içererek (ve bir ifadede gerçekten değiştirilemez), koda koyun.

Çöp dökümü DB'lerinden kaçının

Tüm işletme mantığını uygulama koduna yerleştirme girişimleri, muhtemelen (ilişkisel) veritabanını, ilişkisel tasarımın çoğunlukla tamamen ihmal edildiği, verilerin tutarsız herhangi bir duruma sahip olabileceği ve normalizasyonun eksik olduğu (çöplükle XML, JSON , CSV vb. Çöp kutusu sütunları).

Yalnızca bu tür bir uygulama mantığı, NoSQL'in yükselmesinin temel nedenlerinden biridir - tabii ki, uygulamanın yıllarca ilişkisel veri tabanı içine yerleştirilmiş olan tüm mantığa bakması gerekliliği dezavantajlıdır. Bununla birlikte, NoSQL veritabanları bu tür veri işleme için daha uygundur; örneğin, veri belgeleri kendi içinde gizli bir "ilişkisel bütünlüğü" korur. İlişkisel DB'ler için, sadece daha fazla belaya neden olan, suiistimaldir.

Usul kodu yerine İfadeler (set tabanlı)

En iyi durumda, her veri sorgusu veya işlemi prosedürel kod yerine ifade olarak kodlanmalıdır. Bunun için büyük bir destek, programlama dilleri, .NET dünyasında LINQ gibi ifadeleri desteklerken (ne yazık ki, yalnızca şu anda sorgular, manipülasyon yok). İlişkisel DB tarafında, yordamsal imleç döngüleri yerine SQL deyimi ifadelerini tercih etmek uzun zamandır öğretilmiştir. Böylece, DB işlemi optimize edebilir, paralel olarak yapabilir veya ne işe yarayabilirse.

DB veri bütünlüğü mekanizmalarını kullanın

Yabancı Anahtar ve Kontrol kısıtlamaları olan RDBMS, hesaplanan sütunlar, muhtemelen tetikleyiciler ve görüşler söz konusu olduğunda, temel iş mantığını veritabanında depolamak için burasıdır. Doğru normalleştirme, verinin benzersiz ve farklı bir örneğini sağlamak için veri bütünlüğünü korumaya yardımcı olur. Kod ve veri tabanı içinde kopyalamanız gerekse bile, veri bütünlüğünün bu temel mekanizmaları ihmal edilmemelidir!

Saklı İşlemler

Veritabanları SQL için derlenmiş yürütme planlarını sürdürdüğü ve aynı sorgu tekrar geldiğinde, sadece farklı parametrelerle tekrar kullandıklarından Saklı Prosedürler nadiren gereklidir. Dolayısıyla, SP'ler için önceden derleme argümanı artık geçerli değil. Biri, çoğu zaman önceden derlenmiş sorgu planlarını bulan uygulama veya ORM'de SQL sorgularını saklayabilir veya otomatik olarak oluşturabilir. SQL, açıkça işlemsel unsurları kullanmadığınız sürece bir ifade dilidir. Bu nedenle, en iyi durumda, SQL'e çevrilebilecek kod ifadelerini kullanırsınız.

Oluşturulan ORM dahil olmak üzere uygulama tarafı, SQL, saklı yordamlardan farklı olarak artık veritabanının içinde kalmamasına rağmen, hala veritabanı kodu olarak sayıyorum. Çünkü hala SQL ve veritabanı bilgisi gerektiriyor (en basit CRUD hariç) ve eğer doğru uygulanırsa, genellikle C # veya Java gibi programlama dilleri ile oluşturulan prosedürel koddan oldukça farklı çalışır.

Gerçekten işe, kültürüne ve mirasına bağlı. Teknik hususlar bir yana (bunlar her iki taraftan da ele alınmıştır) verilen cevaplar, insanların nereden geldiğini söylemektedir. Bazı organizasyonlarda veri kraldır ve DBA güçlü bir rakamdır. Bu, tipik merkezi ortamınız, ekli terminallerin bulunduğu bir veri merkezi. Bu tür bir ortamdaki tercih açıktır. Veri merkezindeki herhangi bir şey değişmeden önce masaüstü birçok kez kökten değişebilir ve aralarında çok az şey olur.

Spektrumun diğer ucu ise saf 3 katmanlı mimaridir. Ya da belki web odaklı bir işletmede çok katmanlı. Burada muhtemelen farklı bir hikaye duyacaksınız. DBA, varsa, bazı idari görevleri yerine getiren bir yardımcı olacaktır.

Modern zamanlar uygulama geliştiricisi, ikinci modele daha fazla benzeyecek. Büyük bir müşteri-sunucu sistemi ile büyüdüyseniz, muhtemelen diğer kampta olacaktınız.

Burada sık sık teknik olmayan çevre ile ilgili faktörler vardır, bu sorunun genel bir cevabı yoktur.

İş mantığı terimi yorumlamaya açıktır. Sistemleri kurarken, veritabanının ve içeriğinin bütünlüğünü sağlamak istiyoruz. İlk adım olarak, farklı kullanıcı erişim hibeleri mevcut olmalıdır. Çok basit bir örnek olarak, bir ATM uygulamasını düşünelim.

Hesap bakiyesini almak için, uygun görünümde bir seçim yapmak iyi olmalı. Ancak, para transfer etmek için işlemin saklı bir prosedürle kapsanmasını istersiniz. İşletme mantığının, kredi ve borç tutarları için tabloları doğrudan güncellemesine izin verilmemelidir.

Bu örnekte, işletme mantığı, transfer talebinde bulunmadan önce dengeyi kontrol edebilir veya sadece transfer için depolanmış proc'u çalıştırabilir ve hatayı rapor edebilir. İş mantığı olan IMHO, bu örnekte, yeterli oranda fon bulunduğunu ve hedef hesabın var olduğunu ve ancak daha sonra havale fonlarını çağırdığını önleyici olarak kontrol etmelidir. İlk adımlar ile depolanan proc çağrısı arasında başka bir borçlanma olursa, ancak o zaman bir hata döndürülür.