Tekli V / s Çoklu Veritabanları

Çeşitli kuruluşlar (şu anda yaklaşık 20 müşteri) için bilgi depolayan bu web uygulaması (php & mysql) inşa ettik.

Mevcut senaryo, istemciyle ilgili bilgileri ayrı veritabanlarında depolar, bu nedenle 20 istemci veritabanı ve 1 ana veritabanı vardır.

Buradaki ana avantajlardan biri, her bir müşteri db'si izole edildiğinde, müşteri yapılarının (raporlar, denetimler) vb. Sıralanmasıdır; müşterilerimize güvenlik hissi veriyor.

Her DB yaklaşık 15 tabloya sahiptir ve bir tablodaki en fazla satır yaklaşık 2000'dir. Bunun en fazla 5000 kayda kadar çıkması beklenir.

Tek bir db düzeyi değişikliği yönetmek 20 veritabanını değiştirme anlamına gelir, ancak böyle bir değişiklik yapmanız gereken nadir olay, ben tek bir işlev çağrısı bunu yapan bir komut dosyası kullanın.

Paylaşılan bir barındırma düzenlemesindeyiz ve İSS'miz bize sınırlı bir hayır sağlıyor. veritabanları; ve beni veritabanını merkezileştirme konusunda düşünmeye iten de buydu; Böylece TÜM istemci verileri ana veritabanında saklanabilir.

Elbette, ortaya çıkan bazı önemli konular şunlardır:

a. Artefakt sekansının korunması (ek bir referans anahtarı oluşturularak ele alınabilir) b. Hız ve performans (bu durumda işleri hızlandırmak için dizinler oluşturabilirim) c. Güvenlik: Bu, istemci bilgilerini alan her sorgu olarak yönetilecektir. ayrıca client_id'lerini de takip edecek

Gelecekte, bir kuruluşun veri kümelerini diğeriyle karşılaştırmayı düşünebiliriz, ancak bunun merkezi bir db'de de elde edilebileceğine inanıyorum. Ben (performans ve sürdürülebilirlik nedenleriyle) merkezi bir veritabanına taşınmaya eğilimli.

Merkezi bir veritabanına geçmenin bizim olduğumuzdan (bireysel veritabanlarında) kalmaktan daha anlamlı olduğunu düşünüyor musunuz?

Tavsiyeniz için teşekkürler.

Her iki sistem için de miras riskleri ve ödülleri vardır. 1 veritabanında yaklaşık 40 müşteriyi (ulusal bankalar) destekleyen bir finans firmasında çalıştım. Daha sonra benzer yazılım satan ve müşteri başına 1 veritabanı ile giden başka bir şirket satın aldık. Sonunda şirket iflas etti ve tüm kullanıcı verilerini dışa aktarmak zorunda kaldık. İşte birlikte çalıştığım insanlar:

Tek DB profesyonelleri:

1. Yazılım güncellemeleri ve hata düzeltmeleri daha kolaydır.
2. Tüm müşteri verilerini yönetmek ve raporlamak kolaydır.
3. Verilerin güncellenmesi kolaylaşır.
4. 1 istemcinin istediği modüler işlevsellik oluşturmak kolaydır, diğer istemciler için kapatırsanız ve daha sonra istediklerinde bir tane çevirir.

Tek DB Con:

1. Veri bütünlüğü - 1 bankanın kullanıcılarının başka bir bankanın verilerini gördüğü 2 veya 3 vakamız vardı. Bu bir kabustu. Özellikle site kullanıcıları sadece banka çalışanları değil, bankanın gerçek müşterilerini elinde tutuyorlardı! Bu 1 veritabanı ile açık ara en büyük sorun
2. İstemci verilerini dışa aktarma -Bunu yaptığımız zaman genellikle büyük bir sorun değildi. Tüm istemcileri içeren 1 tablo ile sonuçlanır ve istemcinize özel verileri almak için bu tabloyu kapatırsınız.

Çoklu DB profesyonelleri:

1. İstemciler arası veri kontaminasyonu veya ihlallerine ilişkin bir endişe yoktur
2. İstemci verilerinin dışa aktarılması son derece kolaydır.

Con Çoklu DBs:

1. Güncellemeler ve hata düzeltmeleri - Bu gerçek bir kabus oldu. 20 farklı veritabanında 20 müşteriniz olduğunda, 1 istemcinin bir hatanın düzeltilmesini istediği ve başka bir hatanın bir özellik olduğunu düşündüğü veya güncellemeyi riske atmak istemediği bir duruma hızla girersiniz. Ayrıca, 1 istemcinin oyun değiştiren bir geliştirme istediği, ancak diğer istemcilerin istemediği durumlarınız olacaktır. Bu durumda veritabanlarınız ayrılmaya başlayacaktır. Aniden 1-15 istemcilerini 1 komut dosyası 16-19 ile diğerini 20 ve üçüncüsü ile 20 güncellemeniz gerekecektir. Bunun, bir hata düzeltmesinin satın aldığımız şirket için bizden 15 ila 20 kat daha uzun süreceği gibi bir sorun olduğunu gördük çünkü her müşteri için tüm testleri yapmak ve her müşteriye özel kod ile uğraşmak zorunda kaldılar. Etkili bir şekilde, her yeni müşteri için yeni bir destek personeline ihtiyaçları vardı,
2. DB yönetimi - Tüm veritabanlarını yöneten çok sayıda istemciye ulaştığınızda gerçek bir güçlük haline gelir. Şüphesiz onları yönetmek için daha fazla DBA zamanına ihtiyacınız olacak.

Sonunda benim gördüm ve her ikisi de yapılan benim tavsiye "disiplin" etmektir! Bence çok db seçimi biraz daha iyi çünkü sizi koruyor, ancak istemcilerin sadece onlara işlevsellik eklemenize neden olan bir seçim yapmasına izin veremezsiniz ya da kendinizi başarısızlık yoluna koyacaksınız.

Ayrı istemciler için ayrı bir veri tabanım olurdu. İstemci güvenlik nedeniyle bunu isteyebilir - yani yalnızca sitelerinin verilerine erişimi vardır. Ayrıca, bir istemci verilerini taşımak istiyorsa , yönetilmesi çok daha kolay olacaktır.

Ayrıca, bir müşterinin veritabanında bir sorun varsa, diğerlerinin tümünü etkilemediği anlamına gelir.

İstemciler arasındaki verileri karşılaştırmak istiyorsanız, bunu ayrı olarak yapmanız gerekir.

Sahip olabileceğiniz veritabanlarınız bitiyorsa, belki de barındırma sağlayıcınızı değiştirmeyi düşünmelisiniz.

Her müşteri için ayrı bir veritabanına sahip olmamamın tek nedeni, 100'ler veya 1000'ler istemci / veritabanınız olacaksa. Bu, veritabanı değişiklikleri yapmak veya tüm veritabanlarında bir şeyler yapmak da dahil olmak üzere gerçekten kıllı olabilir. Çok sayıda birden çok veritabanında gerçekleşen eylemler, çok fazla tablo açmanız (ve bu nedenle kapatmanız) gerektiğinden yavaş olabilir.

Ancak bu durumun dışında, birden çok veritabanının daha iyi olduğunu düşünüyorum.

Önemli olmayan ancak faydalı olabilecek bir avantaj, her istemcinin kendi sıralı kimliklerini almasıdır (başka bir istemci (ler) kayıtları eklediğinden muhtemelen bir demet atlamak yerine).

Ayrıca, birden çok veritabanı, alt tabloların (telefon türü gibi), bu tablolarda üst kayıt kimliğine gerek kalmadan istemci başına kolayca özelleştirilebilmesini sağlar.

Önce eser dizisi. Bunu sağlamak için tamsayı birincil anahtarları kullandığınızı varsayıyorum. Gerçekten ayrı bir "yapı numarası" sütununa sahip olmalısınız. PK'lar PK'lar olmalı ve başka bir şey olmamalıdır. İnsanlar "doğal anahtarlar" ve benzerleri hakkında konuşur ve ben kandırırım. Ne zaman bir tanımlayıcıdan daha fazlası için PK'ya güvenirseniz, sizi ısırmaya geri döner. Bir şeyin sırasını bilmek istiyorsanız, bir tarih veya sıra numarası saklayın.

Bence durumunuzda yönetim yönetimi sizi tek bir veritabanına yönlendirir. Veritabanlarını korumak ve yükseltmek için zamanınızın maliyetine bakın. Yazılımın her sürümüyle hangi maliyetler ilişkilendirilir? Ayrıca, yeni bir müşteri aldığınızda ve bir DB oluşturup uygulamayı bunun için yapılandırmanız gerektiğinde maliyeti düşünün. Her şey otomatikleştirilebilir, soru şu ki, 100 veritabanınız olduğunda buna değecek mi?

Yolda, tek bir veritabanını ölçeklendirmek (bölümleme, donanım, parçalama vb.) 100 veritabanında aynısını yapmaktan daha kolaydır.

Ben bu üzerinden gitmek alışkanlık diğer posterler bazı mükemmel noktalar yapmış düşünüyorum.

Şimdiye kadar listelenen pro / con'lara eklemek için:

Birden çok veritabanının profesyonelleri:

1. Kilitleme sorunlarından kaçınılır; istemcilerin bazı tablolarda DDL değişikliklerini tetikleyebilecekleri veritabanlarımız var. Daha büyük tablolar için (> 2m kayıtlar) bu, tabloyu önemli miktarda kilitler. Dezavantajlı insanlar sadece kendi kullanıcılarıdır, bu yüzden bu kabul edilebilir.

2. Esneklik - bazı müşterilerin saklamak istedikleri verilerle ilgili özel istekleri vardır; çoklu veritabanı, diğer istemciler için veri modelini karıştırmak zorunda kalmadan veritabanlarını özel olarak değiştirme esnekliğine izin verdi.

Eksileri:

1. Major con: Diğer masalara katılmak çok daha külfetlidir. Çoğu meta veri içeren bir Ana veritabanımız var. İstemciye özgü veritabanı kullanıcılarının bu veritabanına erişimi yoktur, bu nedenle bu veritabanındaki tablolar ile istemciye özgü tablolar arasındaki tüm birleşimler veritabanında değil uygulamada işlenir. Bunu, istemciye özgü kullanıcılara ana veritabanına erişim vererek çözebilirsiniz, ancak uygulama tekrar bilgi sızdırabilir / sızdırabilir.

Seçiminde iyi şanslar!

Zaten bir cevap seçtiğinizi biliyorum, ancak önerilmeyen başka bir çözüm var gibi görünüyor:

Her şeyi bir veritabanına taşıyın, ancak aşağıdaki gibi bir önek kullanarak her müşteri için tablolar oluşturun:

initec_contacts_tbl
initec_accounts_tbl
initec_personel_tbl
...
masterco_contacts_tbl
masterco_accounts_tbl
masterco_personel_tbl

Her iki dünyanın da en iyisi.

• Mevcut kurulumunuzdan yeni kuruluma geçmek çok kolaydır.
• Müşteri başına 1 kullanıcı oluşturabilir ve ayrıcalıklarını şirketinin tablolarıyla sınırlandırabilirsiniz ve başka hiçbir şey yapamazsınız.
• Gerekirse bir süper kullanıcı oluşturabilir ve verileri kolayca toplayabilirsiniz.
• Yalnızca bir veritabanı kullanın