У меня есть веб-приложение, которое я создал для транспортной компании, которую я хотел бы предложить в качестве SaaS. Каков наилучший способ разработки базы данных?
Должен ли я создать новую базу данных для каждой компании? Или я должен использовать одну базу данных с таблицами с префиксом названия компании? Или я должен использовать одну базу данных с одной из каждой таблицы и просто добавлять в таблицы поле идентификатора компании? Или есть другой способ сделать это?
столкнувшись с аналогичной ситуацией около 10 лет назад, мы выбрали базу данных для каждого клиента. у нас есть сотни (не тысячи) клиентов. оглядываясь назад, это было одно из лучших решений, которые мы приняли. резервные копии просты. копирование одного клиента в наш офис для анализа очень просто (просто возьмите последнюю резервную копию). масштабирование легко (перемещение одного большого клиента на другой сервер может освободить ресурсы на напряженном сервере sql). joel и jeff обсуждали это на подкасте (не последний), и joel сделал то же самое, что и я... каждый клиент получает свою собственную базу данных, пуристы в базе данных часто будут спорить о том, чтобы объединить всех в один бит, но я бы никогда этого не сделал.
-don
Должен ли я создать новую базу данных для каждой компании?
Да - Дон Дикинсон был на деньги. Однако см. Уточнение ниже.
Или я должен использовать одну базу данных с таблицами, которые имеют префикс название компании?
Нет, нет! Изменение запросов к базе данных для разных клиентов сделает вас безумными! Кроме того, вы почти наверняка запускаете динамический SQL (где имя таблицы изменяется в коде перед запуском запроса), что может повредить производительности, поскольку большинство серверов предпочитают кэшировать планы запросов и промежуточные результаты - это не работает, если имена таблиц продолжайте меняться.
Или я должен использовать одну базу данных с одним каждой таблицы и просто добавить компанию id в таблицы?
Возможно, вы захотите сделать это, если хотите, чтобы у ваших клиентов была какая-то масштабируемая модель. В то время как предоставление новой базы данных для каждого клиента дает вам большую гибкость, это также связано с затратами и сложностью. Вам нужно создать новый график резервного копирования, иметь модель жизненного цикла для работы с истекшими клиентами и т.д.
Итак, вы можете сказать, что клиенты "бесплатной пробной версии" и "бронзы" все сосредоточены в одной базе данных, используя идентификатор компании, чтобы отделить их; "Серебряные" пользователи получают свою собственную базу данных (но вы все равно сохраняете поле customer_id в схеме, поэтому вам не нужно менять запросы между двумя уровнями клиентов), а "золотые" клиенты получают свой собственный сервер базы данных.
Я сделал что-то подобное несколько лет назад в компании SaaS, и клиенты, как правило, счастливы иметь путь обновления инфраструктуры (читай: производительность и устойчивость), а также функции.
В чем преимущества использования единой базы данных для клиента EACH?
Должен ли я использовать одну или несколько настроек базы данных для многоклиентского приложения?
https://stackoverflow.fogbugz.com/default.asp?W24218 (транскрипт подкаста, обсуждение около 50 минут)
У нас есть несколько баз данных с общими клиентами и некоторые, где каждый клиент имеет собственный сервер и собственную базу данных. Те, в которых клиент находится на своем собственном сервере, являются самыми легкими в управлении и наименее вероятными могут возникнуть проблемы, когда какой-то разработчик забыл случайно добавить клиента и отправил клиенту данные клиенту b (пример НЕ выбран случайным образом).
Сохранение на своем собственном экземпляре сервера или сервера позволяет сохранить структуру базы данных одинаковой с одинаковыми именами и упростить распространение изменений на всех серверах, потому что нам не нужно менять имя базы данных.
Если вы используете отдельные экземпляры для каждого клиента, убедитесь, что вы разрабатываете и внедряете хорошую систему для распространения всех изменений для всех клиентов. Если эти базы данных не синхронизируются, они могут стать ужасными для поддержания. Вы обнаружите, что если вы позволите им выйти из синхронизации, каждый клиент попросит об изменениях, и у вас будет 27 способов сделать то же самое. Вы должны обобщать, когда они находятся в одной базе данных, когда они являются отдельными, вы должны использовать самодисциплину, чтобы гарантировать, что новые функции одинаковы для каждого клиента.
Это зависит от того, как я работаю в компании, где многие "внутренние бизнес-единицы" рассматриваются как другие компании. Таким образом, в некоторых отчетах должны быть представлены все компании, учетные записи клиентов также должны быть доступны для разных компаний. Здесь у нас есть поля CompanyId в таблицах, которые этого требуют. Префиксное решение, безусловно, следует избегать.