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

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

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

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

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

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

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

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

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

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

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

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

Это также зависит от вашего RDBMS например

С SQL серверными базами данных идет чип

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

Однако каждый раз, когда вы выбираете ведьму, старайтесь скрыть ее как низкий уровень в вашем коде доступа к данным

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

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

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

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

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

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

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

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