Объединение базы данных для нескольких клиентов - хорошая идея?

Question

Я присоединился к небольшой компании, которая по сути продает одно веб-приложение. Данные в веб-приложении очень чувствительны до такой степени, что все данные шифруются на уровне поля. Приложение написано в ASP.NET Web API 2 (C#), с интерфейсом html/javascript и SQL-сервером.

На данный момент у них около 50 клиентов, а архитектура приложения заключается в том, что каждый клиент получает свою собственную базу данных. Все они развернуты в свой собственный виртуальный каталог IIS, который затем указывает на собственную БД. Код точно такой же среди всех клиентов.

Владелец сказал мне, что это все по дизайну для обеспечения безопасности. Тем не менее, это абсолютная боль для управления, и они только когда-либо получают больше клиентов.

Я предложил объединить все это в одну БД и добавить поле в основной таблице, которое идентифицирует, к какому клиенту принадлежат данные. Отсюда я могу фильтровать/присоединяться к этому полю.

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

Есть ли какой-либо возможный способ рискнуть этим? Я предложил переопределить класс авторизации, чтобы остановить доступ к информации неавторизованным пользователям, но это не решает проблему «плохого кода».

Есть ли что-нибудь, что я могу сделать, или я застрял, сохраняя целую кучу баз данных?

Answer 1

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

Если вы решили сохранить отдельные базы данных, это звучит так, как вам нужно инвестировать в автоматизацию, чтобы помочь им справиться. Мы используем проект базы данных для управления исходными кодами схемы/сценариев базы данных и MSDeploy для автоматизации развертываний во всех базах данных. Возможно, это увеличит часть вашей боли с помощью нескольких баз данных.

http://dotnetcatch.com/2016/02/10/deploying-a-database-project-with-msdeploy/

Answer 2

Я не думаю, что здесь есть право или неправильный ответ здесь, это действительно до аппетита к риску данной компании (или ее владельца).

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

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

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

В MSDN есть хорошая статья, которая рассматривает все 3 варианта: Multi-Tenant Data Architecture. В статье описываются преимущества и недостатки всех трех сценариев.

Однако, пожалуйста, помните, что все это действительно зависит от субъективного риска вашего предприятия!