Как создать базу данных SaaS - PullRequest
18 голосов
/ 04 февраля 2010

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

Должен ли я создать новую базу данных для каждой компании? Или я должен использовать одну базу данных с таблицами, которые имеют префикс названия компании? Или я должен использовать одну базу данных с одной из каждой таблицы и просто добавить поле идентификатора компании в таблицы? Или есть другой способ сделать это?

Ответы [ 5 ]

26 голосов
/ 04 февраля 2010

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

-don

9 голосов
/ 18 марта 2011

Должен ли я создать новую базу данных для каждой компании?

Да - Дон Дикинсон был на деньги. Тем не менее, см. Уточнение ниже.

Или я должен использовать одну базу данных с таблицами, которые имеют префикс название компании?

Господи, нет! Изменение запросов к базе данных на разные для клиента заставит вас сойти с ума! Кроме того, вы почти наверняка запустите динамический SQL (где имя таблицы изменяется в коде перед выполнением запроса), что может снизить производительность, так как большинству серверов нравится кэшировать планы запросов и промежуточные результаты - это не работает, если имена таблиц продолжай меняться.

Или я должен использовать одну базу данных с одной каждой таблицы и просто добавить компанию поле id для таблицы?

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

Таким образом, вы можете сказать, что «бесплатные пробные» и «бронзовые» клиенты объединены в одну базу данных, используя идентификатор компании для их разделения; «Серебряные» пользователи получают свою собственную базу данных (но вы все равно сохраняете поле customer_id в схеме, поэтому вам не нужно менять запросы между двумя уровнями клиентов), а «золотые» клиенты получают свой собственный сервер базы данных.

Несколько лет назад я проделал нечто подобное в компании SaaS - и клиенты, как правило, рады возможности обновления инфраструктуры (читай: производительность и отказоустойчивость), а также функций.

2 голосов
/ 04 февраля 2010

У нас есть несколько баз данных с общими клиентами, а некоторые - с собственным сервером и собственной базой данных. Те, где клиент находится на своем собственном сервере, являются самыми простыми в управлении и имеют наименьшую вероятность возникновения проблемы, когда какой-то разработчик забыл добавить клиентскую информацию и случайно отправил данные клиента a клиенту b (пример, выбранный НЕ случайно).

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

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

1 голос
/ 04 февраля 2010

Здесь я работаю в компании, в которой многие «Внутренние бизнес-единицы» работают так же, как и другие компании. Таким образом, некоторые отчеты должны включать все компании, учетные записи клиентов также должны быть разделены между компаниями. Здесь у нас есть поле CompanyId в таблицах, которое требует этого. Префиксного решения, безусловно, следует избегать.

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