Одна база данных или много?

Question

Я занимаюсь разработкой веб-сайта, который будет управлять данными для нескольких организаций. Данные не передаются между объектами, но они могут принадлежать одному и тому же клиенту. Клиент может захотеть управлять всеми своими объектами из единой «панели инструментов». Таким образом, я должен иметь одну базу данных для всего или держать данные разделенными на отдельные базы данных? Есть ли лучшая практика? Каковы положительные / отрицательные стороны для:

• база данных для всего сайта (субъекта) имеет "идентификатор клиента", данные имеют "EntityId")
• база данных для каждого клиент (данные имеют "entityID")
• база данных для каждого субъекта (отношение база данных для клиента находится за пределами базы данных)

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

Answer 1

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

1. Меньше = быстрее в отношении запросов.
2. Запросы проще.
3. Нет риска случайного отображения данных одного клиента другому.
4. Одна база данных может создать узкое место в производительности, поскольку она становится большой (количество объектов увеличивается). Вы получаете некое построение горизонтальной масштабируемости с 1 на сущность.
5. Простая очистка данных при удалении клиентов или организаций.

Конечно, для обновления схемы потребуется больше времени, но, по моему опыту, изменения довольно редки после развертывания, а добавления тривиальны.

Answer 2

Я думаю, что на это трудно ответить без дополнительной информации.

Я опираюсь на одну базу данных. Правильно закодированные бизнес-объекты должны препятствовать тому, чтобы вы забыли clientId в своих запросах.

Тип используемой базы данных и ее масштабирование могут помочь вам принять решение.

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

Answer 3

Ознакомьтесь с этой статьей на сайте Microsoft. Я думаю, что это отличная работа по выявлению различных затрат и выгод, связанных с проектами с несколькими арендаторами. Также посмотрите статью Multi tenancy в Википедии. Есть много компромиссов, и ваш лучший выбор во многом зависит от того, какой тип продукта вы разрабатываете.

Answer 4

Это довольно нормальный сценарий в мультитенантных приложениях SAAS. Оба подхода имеют свои плюсы и минусы. Ищите лучшие практики для мультитенантного SAAS (программное обеспечение как услуга), и вы найдете тонны материала для размышления.

Answer 5

Как насчет резервного копирования и восстановления? Не могли бы вы обратиться к клиенту, желающему восстановить резервную копию одного из своих объектов?

Answer 6

Опция единой базы данных значительно упростит обслуживание.

Answer 7

Планируете ли вы развернуть свой код в нескольких средах?

Если это так, попробуйте сохранить его в одной базе данных и иметь все ссылки на таблицы с префиксом пространства имен из файла конфигурации.

Answer 8

Это также зависит от вашей СУБД, например.

С SQL-сервером базы данных дешевы

С Oracle легко разделить таблицы по «идентификатору клиента» клиента, поэтому одна большая база данных может работать так же быстро, как небольшая база данных для каждого клиента.

Как бы то ни было, старайтесь скрыть это как низкий уровень в вашем коде доступа к данным

Answer 9

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

ИМХО, наличие данных для нескольких клиентов в одной базе данных кажется мне плохой идеей. Вы должны помнить, чтобы всегда фильтровать ваши запросы по clientID.

Answer 10

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