Мульти-оренда - одна база даних проти декількох баз даних

У нас є декілька клієнтів, системи яких поділяють певну функціональність, але також мають достатню ступінь різноманітності. Зростає кількість клієнтів - завжди здорова річ! - і різноманітність між їхніми підприємствами також збільшується.

В даний час існує єдиний веб-сайт ASP.Net (Web Forms) (на відміну від веб-проекту), на якому є підпапки для кожного орендаря, з нестандартними сторінками цього орендаря. Існує окремий модельний проект, який стосується доступу до бази даних та логіки бізнесу.

Що є кращим - а головне, чому - між наявністю (а) 1 бази даних на кожного клієнта, з лише функціями, пов'язаними з цим клієнтом; або (b) єдину базу даних, яку поділяють усі клієнти, де будь-який клієнт використовує лише підмножину таблиць.

Основні проблеми в бізнесі закінчуються:

• обслуговування декількох активів - резервного копіювання, контролю версій тощо
• максимально сприяючи повторному використанню

Як би ви забезпечили вирішення цих проблем, яке рішення є кращим і чому? (Я також збираю відповіді на подібні запитання)

Ось основні моменти досліджень з інших джерел (спочатку з редакції 2 питання ):

• Чи слід використовувати одну базу даних на додаток або ділити одну базу даних між кількома програмами

• Підтримка багатожиття

• MSDN архітектура даних для багатьох орендарів

• ТАК Як створити базу даних для багатьох орендарів із спільними структурами таблиці?

• CloudExpo SaaS - Параметри дизайну бази даних для багатьох орендарів

• Блоги MSDN Перехід на багатозахисну модель бази даних, спрощена за допомогою SQL Azure Federation

• Запитати базу даних SQL Server Central One або декілька?

• Центральне змішування таблиць SQL Server з різних баз даних / програм в одну базу даних

• Блог Ayende @ Rahien Multi- орендарі - фізична модель даних

• Код проекту, архітектура баз даних декількох орендарів

• Джоель на розробці баз даних багатопрофільних програм

• ТАК Кілька додатків за допомогою однієї бази даних?

• ТАК Одиночна чи кілька баз даних

• Code Rant - багатожитлова частина, частина 1, стратегія та частина 2, компоненти та контекст

Якщо ви використовуєте SQL Server, використовуйте одну базу даних, але використовуйте схеми. Використовуйте dbo для речей, загальних для всіх клієнтів, і створіть схему для кожного клієнта та зробіть схему за замовчуванням для користувачів цього клієнта. Тепер ви можете мати загальний об'єкт (скажімо, getBudget proc) в схемі dbo та індивідуальний для клієнта в їх однойменній схемі.

Оскільки бази даних і функціональність клієнтів розходяться, то це означає, що в один момент вони виявляться різними системами, тому в цьому випадку я рекомендую окремі системи, оскільки витрати на підтримку налаштувань для кожного клієнта будуть переважати від переваг одного система баз даних.

Єдині системи баз даних найкращі, коли зміни між різними клієнтами - це лише конфігурація, але не додаткові функції для кожного клієнта.

Вам не вистачає певних проблем. Проблеми будуть рости. Якщо ви можете припустити, що коли-небудь ви зросте більше, ніж один сервер БД - одна складна база даних напевно викличе у вас головний біль. Якщо ви не заздалегідь вкладете в архітектуру. Але це також дорогий крок)

Тож, не забувайте, що масштабувати декілька різних баз даних, ніж величезні, це і в багато разів дешевше, і в багато разів)

Однією з областей, яку я не бачив у відповідях, є проблеми з правильним захистом програми для багатообіцяних БД. Додатки для орендарів повинні бути дуже ретельно розроблені, щоб уникнути проблем безпеки. Більшість баз даних та додатків забезпечують певну, але не повну ізоляцію - зазвичай існують способи прямого чи опосередкованого висновку даних у схемах БД. І досить багато спільних ресурсів (журнали та інші файли, таблиці DBA, курсори ...), які, принаймні, можуть призвести до легких атак на відмову від служби на інших орендарів і, як правило, набагато більше.