Çoklu kiracılık - tek veritabanı vs çoklu veritabanı

Sistemleri bazı işlevleri paylaşan, ancak oldukça fazla çeşitliliğe sahip bir dizi müşterimiz var. Müşteri sayısı artıyor - her zaman sağlıklı bir şey! - ve işletmeleri arasındaki çeşitlilik de artıyor.

Şu anda, her kiracının alt klasörleri olan ve kiracının standart olmayan sayfaları olan tek bir ASP.Net (Web Formları) Web Sitesi (web projesinin aksine) vardır. Veritabanı erişimi ve iş mantığı ile ilgilenen ayrı bir model projesi var.

Hangi - ve en önemlisi, neden - tercih edilen (a) sadece bir istemci ile ilişkili özellikleri ile, istemci başına 1 veritabanı olması; veya (b) herhangi bir istemci tarafından yalnızca bir tablo alt kümesinin kullanıldığı tüm istemciler tarafından paylaşılan tek bir veritabanı.

İşletmedeki ana endişeler sona erdi:

• çoklu varlıkların bakımı - yedeklemeler, sürüm kontrolü ve benzerleri
• mümkün olduğunca yeniden kullanımı teşvik etmek

Bu endişelerin ele alınmasını nasıl sağlayacaksınız, hangi çözüm tercih edilebilir ve neden? (Ben de benzer sorulara cevap derliyorum)

Diğer kaynaklardan yapılan araştırmaların öne çıkanları (aslen sorunun 2. düzeltmesinden ):

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

• Çok kiracılığı destekleme

• MSDN Çok Kiracılı Veri Mimarisi

• SO Paylaşılan tablo yapıları ile çok kiracılı bir veritabanı nasıl oluşturulur?

• CloudExpo SaaS - Çok Kiracılı Veritabanı Tasarım Seçenekleri

• MSDN blogları SQL Azure Federasyonlarıyla Çok Kiracılı Veritabanı Modeline Geçme

• SQL Server Central One veya daha fazla veritabanına sorun mu?

• SQL Server Central Farklı veritabanlarından / uygulamalardan tabloları tek bir veritabanında karıştırma

• Ayende @ Rahien blog Çoklu Kiracılık - Fiziksel Veri Modeli

• Kod Projesi Çok Kiracılı Veritabanı Mimarisi

• Yazılımda Kiracı Çok kiracılı veritabanı tasarımı

• SO Bir veritabanı kullanarak çoklu uygulama?

• SO Tekli veya çoklu veritabanları

• Code Rant - Çoklu Kiracılık Bölüm 1, Strateji ve Bölüm 2, Bileşenler ve Bağlam

SQL Server kullanıyorsanız, bir veritabanı kullanın ancak şemalar kullanın. Tüm istemciler için genel olan şeyler için dbo kullanın ve her istemci için bir şema oluşturun ve bu istemciden kullanıcılar için varsayılan şemayı yapın. Artık dbo şemasında genel bir nesneye (diyelim getBudget proc) ve aynı adı taşıyan şemalarında istemci için özelleştirilmiş bir nesneye sahip olabilirsiniz.

İstemciler veritabanları ve işlevsellik birbirinden ayrıldığı için, bir noktada farklı sistemler haline geleceği anlamına gelir, bu nedenle her bir müşteri için özelleştirmeleri koruma maliyetleri tek bir avantajdan daha ağır basacağı için bu durumda ayrı sistemler öneririm. veritabanı sistemi.

Tek veritabanı sistemleri, farklı müşteriler arasındaki değişikliklerin yalnızca yapılandırmalar olduğu, ancak her istemci için ek özellikler olmadığı durumlarda en iyisidir.

Bazı endişeleriniz eksik. Sorunlar büyüme ile gelecek. Bir gün bir DB sunucusundan daha büyük büyüyeceğinizi varsayabilirseniz - karmaşık bir veritabanı kesinlikle baş ağrısına neden olur. Önceden mimariye yatırım yapmadığınız sürece. Ama aynı zamanda pahalı bir adımdır)

Bu nedenle, unutmayın ki, birkaç farklı veritabanını ölçeklendirmek, büyük veritabanlarından hem çok daha ucuz hem de birçok kez daha kolaydır.

Yanıtlarda ele alınmadığını gördüğüm bir alan, çok kiracılı bir DB uygulamasını doğru şekilde güvenli hale getirmeyle ilgili sorunlardır. Güvenlikle ilgili sorunları önlemek için çok kiracılı uygulamaların çok dikkatli bir şekilde tasarlanması gerekir. Çoğu Veritabanları ve uygulamalar bir miktar yalıtım sağlar, ancak tam bir yalıtım sağlamaz - genellikle DB şemalarında doğrudan veya dolaylı olarak veri çıkarmanın yolları vardır. Ve en azından diğer kiracılara kolay Servis Reddi saldırılarına ve genellikle çok daha fazlasına yol açabilen birkaç paylaşılan kaynak (günlükler ve diğer dosyalar, DBA tabloları, imleçler ...).