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

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

  • база данных для всего сайта (у объекта есть «customerID», у данных есть «entityID»)
  • база данных для каждого клиента (данные имеют «entityID»)
  • база данных для каждой сущности (отношение базы данных к клиенту находится за пределами базы данных)

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

11 ОТВЕТОВ

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

1
21.08.2008 15:54:18

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

1
21.08.2008 15:56:40

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

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

Таким образом, главная БД, поддерживаемая несколькими БД для каждого клиента, может быть лучшим подходом,

0
21.08.2008 15:58:26

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

0
21.08.2008 16:00:26

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

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

0
21.08.2008 16:40:13

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

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

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

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

2
21.08.2008 17:47:11

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

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

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

5
28.08.2008 15:26:33

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

1
2.02.2009 17:50:18

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

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

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

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

0
3.09.2009 12:02:49

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

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

0
20.09.2009 12:33:35

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

0
26.04.2010 15:42:34