Uygulama başına bir veritabanı kullanmalı mıyım veya birden fazla uygulama arasında tek bir veritabanını paylaşmalı mıyım [kapalı]

Bazıları aynı kaynaklardan gelen verileri kullanan çoklu uygulamalarım var. En iyi uygulama (veya artıları / eksileri nelerdir):

• verileri birden fazla uygulama tarafından paylaşılan veritabanlarında bırakın

  1. sadece bir veritabanı gerektiğinden yer tasarrufu sağlar
  2. farklı uygulamaların farklı sorgulama ihtiyaçları olduğu için endekslemeyi zorlaştırır

• Günlük verileri uygulama başına veritabanlarına aktar

  1. Uygulama başına veritabanlarında yinelenen veriler bulunduğundan daha fazla alan kullanıyor
  2. Her uygulama bireysel ihtiyaçlarına odaklanabileceğinden daha kolay dizin oluşturma

Başka avantajlar / dezavantajlar dışında bırakmış olabilirim, varsa lütfen listele, işyerinizde bu nasıl yapılır?

Alan bugünlerde ucuz, bu yüzden uygulama başına bir veritabanı kullanmanızı öneririm.

Bir veritabanını birden fazla uygulama arasında paylaşmanın bazı dezavantajları vardır :

• Aynı veritabanını ne kadar fazla uygulama kullanırsanız, performans darboğazlarına çarpmanız ve yükü istediğiniz gibi kolayca ölçekleyememeniz de o kadar olasıdır . SQL Veritabanları gerçekten ölçeklendirilmez. Daha büyük makineler satın alabilirsiniz, ancak kümelerde iyi ölçeklenemezler!

• Bakım ve geliştirme maliyetleri artabilir : Bir uygulamanın eldeki işe uygun olmayan ancak halihazırda olduğu gibi kullanılması gereken veritabanı yapılarını kullanması gerekirse geliştirme daha zordur. Ayrıca bir uygulamanın ayarlarının diğer uygulamalar üzerinde yan etkileri olması muhtemeldir ("neden bu kadar gereksiz bir tetikleyici var?!" / "Artık bu verilere ihtiyacımız yok!"). Geliştiriciler tüm kullanım durumlarını bilmediğinde / bilmediğinde, tek bir uygulama için tek bir veritabanında zaten zor.

• Yönetim zorlaşır: Hangi nesne hangi uygulamaya aittir? Kaos yükseliyor. Verilerimi nerede aramak zorundayım? Hangi kullanıcının hangi nesnelerle etkileşimine izin verilir? Kime ne verebilirim?

• Yükseltme: Kullanarak tüm uygulamalar için en düşük ortak payda olan bir sürüme ihtiyacınız olacak. Bu, bazı uygulamaların güçlü özellikleri kullanamayacağı anlamına gelir. Eski sürümlere bağlı kalmak zorunda kalacaksınız. Ayrıca geliştirme maliyetlerini bir miktar arttırır.

• Eşzamanlılık: İşlemler arasında kronolojik bağımlılıklar olmadığından emin olabilir misiniz? Bir uygulama eski veya başka bir uygulama tarafından değiştirilmiş olması gereken verileri önce değiştirirse ne olur? Aynı masalarda aynı anda çalışan farklı uygulamalardan ne haber?

Bununla karşılaştırıldığında, veri alma / ETL işlemleri neredeyse her zaman oldukça basit ve basittir. Verileri ihtiyaç duyduğunuz sıklıkta yükleyin, alan ucuzdur. Her bir uygulama için ölçeklenebilirliği bağımsız olarak hesaba katabilir, istediğiniz gibi yapıları ayarlayabilir ve ince ayar yapabilirsiniz, ancak eşzamanlılık sorunları olmaz. Yan etkiler de çok daha kolay izlenebilir.

Düzenleme: Yine de belirtmek isterim ki, @Saeed'in dediği gibi, veri manipülasyonlarını yaygın olarak kullanılan bir hizmette saklayabiliyorsanız, bir veritabanını birden fazla uygulama ile paylaşmak daha kolaydır. Ham erişime ihtiyacınız olmadıkça, bu çok iyi bir yaklaşımdır.

Bir zamanlar benzer bir durum yaşadım. Benim sorunum biri stok yönetimi, biri tedarik yönetimi ve biri kullanıcıları yönetmek, yani çalışanlar olmak üzere 3 uygulama oluşturmaktı. Benim tavsiyem, uygulama başına veri tabanlarını fiziksel olarak kırmamak ya da uygulama başına fiziksel olarak katılmak değildir. Aksine, IMHO mantıksal ayrımı daha iyi çalışır.

Örneğin, çalışanların bilgileriyle çalışmak için 3 uygulamanın da ihtiyacı vardı. Hem stok hem de tedarik sistemleri aynı mal ve stok kalemleri bilgisini kullanıyordu.

Kullanıcıların ve malların bilgilerini sakladığım ortak bir veritabanı oluşturdum. Sonra üzerine bir servis katmanı kurdum ve bu servisleri diğer uygulamalarda kullandım. Mesela şu an şirkette olan tüm çalışanların bir listesini göstermek için, yalnızca hizmetten bir yöntem çağırmam gerekiyordu GetOnWorkEmployees().

Ayrıca kendi başına ayrı bir web uygulaması olan kullanıcılar ve ürünlerle etkileşime geçmek için ortak bir UI oluşturdum.

Bu nedenle, @Falcon'un işaret ettiği şeye ek olarak, uygulamalar arasındaki ortak işlevselliği tek bir veritabanında merkezileştirmekten faydalanabileceğinizi düşünüyorum.

Bu uygulamaların aynı verilerle çalışması gerekiyorsa - örneğin, aynı ürün ve müşteri listesi - veritabanını bir arada tutun. Veritabanlarını ayırarak hiçbir şey kazanmazsınız. Bu tamamen 'insani' bir sorun - sunucuya diskteki sadece bayt sayısı. Onun 1 veya 100 veritabanını umursamıyor. Ancak bölüştürüyorsanız, veri senkronizasyonu ile uğraşmanız gerekir. Açtığınız endeksleme sorunları gerçek bir sorun değil - eğer db bölünmüşse, endeksleri koruyarak aynı miktarda işlemciyi harcayacaksınız.

Performans bir sorun olmaya başlarsa, işleri dengelemek için db'yi birden fazla sunucuya kopyalayın.

Durumunuzdaki değiş tokuşa değer olabilir veya olmayabilir, ancak veri bütünlüğünü korumak tek bir veritabanıyla daha kolaydır. MS SQL Server'da en azından bir veritabanından farklı bir veritabanına yabancı anahtar olamaz. Yabancı anahtar davranışını tetikleyicilerle simüle edebilirsiniz, ancak özellikle şık değil.

Ek olarak, yazılanlar devreye girdiğinde verilerin yerel kopyalarını oluşturmak tehlikeli olabilir. AppA ve AppB'de paylaşılan verilerin bir kopyası varsa ve AppA güncellerse, AppB hala eski verilere sahip olacaktır. Veya, verileri senkronize tutmak için tetikleyiciler kurmanız gerekir.

Bir zamanlar popüler olan birden fazla web sitem vardı. Çoğunlukla, barındırma sağlayıcısının her birine yalnızca 1 GB depolama alanına izin verdiği için ayrı veritabanları kullandılar. Fakat! Tüm bu web sitelerini içeren bir hizmet yayınladığımda, bu web siteleri arasında işlem yapmak zorunda kaldım ve bunu yapmanın en kolay yolu kesinlikle her şeyi büyük bir veritabanına taşımak.

Bu yüzden veritabanı yapısını optimize ettim ve ilgili kısımları bu merkezi veritabanına sıkıştırdım, ancak her şeyi dışarıda bıraktım.

Benim fikrim, bir şekilde OOP paradigmalarıyla ilgili. Benzer veriler birlikte depolanmalıdır, bu nedenle farklı uygulamalar oluşturursanız, onlar için farklı veritabanları kullanmanız gerekir.

Yukarıdaki durumda, ortak db kullanmaktan kaçınılmazdı, ancak bazı sorguları ayrı bir db'de, ortak sorguların bir parçası olmayan ayrı tuttuğumu da unutmayın.

Dahası, onları ayrı tutarsanız, yedeklemeleri daha kolay olacak, veri kaybı için daha az şansınız olacak. Bir şeyler ters giderse ve uygulamalar birbirine karışırsa, veritabanı karışır ve temelde uygulamanızı bu tehlikeye maruz bırakmak istemezsiniz.

Sonuç olarak, ortak sorgular için ortak bir veritabanı tutabilir, ancak her bir uygulama için bir tane saklayabilirsiniz.

Uygulama mimariniz hakkında daha fazla bilgi verebilir misiniz?

Veritabanınız, tetikleyiciler veya işletme paketi kodu gibi uygulama mantığı olmayan bir veri deposu gibi çalışıyorsa, tek bir veritabanına sahip olmak ve tüm eylemleri için veritabanını kullanan hizmetlere işletme düzeyinde işlevsellik dahil etmek daha iyi olur. Veritabanı şemasında tetikleyicileriniz veya kodunuz varsa, çoğu durumda zahmetli olabilecek tek bir veritabanını kullanarak başınız büyük belaya girer.