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

20

У нас есть ряд клиентов, чьи системы имеют некоторые функциональные возможности, но также имеют достаточно разнородную структуру. Число клиентов растет - всегда здоровая вещь! - и разнообразие между их предприятиями также увеличивается.

В настоящее время существует один веб-сайт ASP.Net (веб-формы) (в отличие от веб-проекта), который имеет подпапки для каждого арендатора с нестандартными страницами этого арендатора. Существует отдельный модельный проект, который занимается доступом к базе данных и бизнес-логикой.

Что предпочтительнее - и, самое главное, почему - между (а) 1 базой данных на клиента, только с функциями, связанными с этим клиентом; или (b) единую базу данных, совместно используемую всеми клиентами, где только один набор таблиц используется любым одним клиентом.

Основные проблемы в бизнесе закончились:

поддержка нескольких активов - резервное копирование, контроль версий и тому подобное
содействие повторному использованию в максимально возможной степени

Как бы вы обеспечили решение этих проблем, какое решение является предпочтительным и почему? (Я также собираю ответы на похожие вопросы)

database-design projects-and-solutions multitenancy

— RichardW1001
источник

Есть ли вероятность, что это переместится в облачную среду PaaS, такую как Azure? Если это так, вы также захотите рассмотреть лучшие практики для окружающей среды. В прошлый раз, когда я смотрел, MS рекомендовала несколько баз данных для многопользовательского программного обеспечения на Azure.

— Харпер Шелби

Спасибо за вопрос. Я удивлялся подобным вещам, но не смог выразить вопрос так же красноречиво, как вы.

— MathAttack

Вам следует прочитать серию блогов, посвященных многопользовательской работе Ayende. Он делает несколько очень хороших замечаний о множественной и единой базе данных.

— Sebazzz

12

Вот основные результаты исследований из других источников (первоначально из второй редакции вопроса ):

Должен ли я использовать одну базу данных для одного приложения или использовать одну базу данных для нескольких приложений
Поддержка многопользовательского режима
Многопользовательская архитектура данных MSDN
SO Как создать многопользовательскую базу данных со структурами общих таблиц?
CloudExpo SaaS - Варианты проектирования мультитенантной базы данных
Блоги MSDN Переход на мультитенантную модель базы данных стал проще с федерациями SQL Azure
Спросите SQL Server Central Одна база данных или несколько?
SQL Server Central Смешивание таблиц из разных баз данных / приложений в одну базу данных
Ayende @ Rahien blog Multi Tenancy - Физическая модель данных
Архитектура базы данных мультитенантов Code Project
Джоэл о программном обеспечении мультитенантной базы данных
SO Несколько приложений, использующих одну базу данных?
SO Одна или несколько баз данных
Code Rant - многопользовательская часть 1, стратегия и часть 2, компоненты и контекст

— оборота user40980
источник

10

Если вы используете SQL Server, используйте одну базу данных, но используйте схемы. Используйте dbo для вещей, общих для всех клиентов, создайте схему для каждого клиента и сделайте эту схему схемой по умолчанию для пользователей этого клиента. Теперь вы можете иметь общий объект (скажем, процедуру getBudget) в схеме dbo и настраиваемый объект для клиента в их схеме с тем же именем.

— HLGEM
источник

+1 Это также позволит вам избежать необходимости настраивать MSDTC и брать на себя соответствующие накладные расходы (двухфазные коммиты)

— Брайан

Надеемся, что вы избежите ловушки, в которой есть такие столбцы, как CustomField1 - CustomField30 и / или такие таблицы, как Budget, BudgetEx, BudgetCustom, BudgetCustomerName, BudgetAnotherCustomerName и т. Д.

— jfrankcarr

Существует существующий уровень доступа к данным, который использует множество хранимых процедур - 190 таблиц, 5 процедур, сгенерированных кодом для каждой таблицы, плюс несколько пользовательских - в то время как среднесрочной целью является внедрение Entity Framework, возникнет ли необходимость в репликации хранимых хранимых процедур. процедуры для каждой схемы?

— RichardW1001

@ RichardW1001: зависит. Вы можете делать динамический SQL в sp, чтобы сделать его универсальным, но это, конечно, зависит от того, что они имеют хотя бы несколько похожую структуру. Возможной альтернативой для динамического sql могут быть синонимы , к сожалению, насколько я понимаю, они являются системными и не содержатся в транзакции, поэтому не подходят для одновременного использования с другими значениями.

— Jmoreno

Если мы используем несколько схем, с помощью EF Code First можно ли будет перенести все схемы на последнюю версию после запуска системы?

— Яшвит

4

Поскольку базы данных и функциональные возможности клиентов расходятся, это означает, что в какой-то момент они окажутся разными системами, поэтому в этом случае я бы порекомендовал отдельные системы, поскольку затраты на обслуживание настроек для каждого клиента перевесят преимущества одного система баз данных.

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

— Стивен Сенкомаго Мусоке
источник

Что бы вы посоветовали относительно того, как управлять общей функциональностью с минимальной болью?

— RichardW1001

1

В вашей системе управления версиями ведите голову для основного приложения и создайте основную ветвь для каждого клиента с подотделами для новых функций, которые им необходимо поддерживать. Разрабатывайте специфичные для клиента функции в филиалах с возможностью обновления соединительной линии и т. Д. Затем вы можете легко раскручивать специфичные для клиента среды в

— любое время,

3

Вы пропускаете некоторые проблемы. Проблемы придут с ростом. Если вы можете предположить, что когда-нибудь вы станете больше, чем один сервер БД - одна сложная база данных определенно вызовет у вас головную боль. Если вы не будете вкладывать средства в архитектуру заранее. Но это тоже дорогой шаг)

Так что просто не забывайте, что и во много раз дешевле, и во много раз легче масштабировать несколько разных баз данных, чем огромные)

— стим
источник

У вас есть данные, подтверждающие легкость масштабирования? Если так, то это будет очень убедительным аргументом. Не могли бы вы уточнить другие недостающие проблемы? Я пытаюсь построить как можно более полный аргумент с обеих сторон.

— RichardW1001

1

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

— эгрет
источник