Ответ 1
Вы должны взвесить свои варианты, так как некоторые из них будут предметом мнений и могут оказаться невыполнимыми для вашей реализации.
Учитывая сказанное, я бы рассмотрел подход к единой базе данных по следующим причинам:
-
Обслуживание: при запуске базы данных на зарегистрированного "клиента" вы очень легко достигнете ситуации, когда любые изменения или обновления, которые вы вносите в схему приложения, должны применяться к каждому экземпляр базы данных. Это будет смешно, быстро.
-
Удобство. Вам может понадобиться аналитика и статистика использования, или какой-либо способ администрирования всех этих баз данных. Запрос одной базы данных сравнительно тривиален, чтобы попытаться агрегировать один и тот же запрос для всех ваших баз данных. Это не будет масштабироваться.
-
Масштабируемость *: Как уже упоминалось в 2, вам понадобится особый тип агрегации, чтобы запрашивать информацию о ваших клиентах и вашем приложении в целом. Чем больше ваше приложение, тем сложнее ваш запрос. Другая проблема заключается в том, что если один клиент использует приложение намного больше, чем другой, что вы будете оптимизировать? Ваше приложение, большая клиентская база данных или меньший клиент? Не забывая ничего, что вы делаете, изменения должны быть скопированы во все базы данных.
-
Резервные копии. Вы можете легко создать резервную копию одной базы данных, просто создав дамп и скопировав его где-нибудь. Получите тысячу клиентов, и теперь вам нужно запустить 1000 дампов базы данных и назовите их достаточно хорошо, чтобы их можно было идентифицировать, если одна отдельная база данных развращает. Как вы узнаете, если это произойдет? Ошибки базы данных будут локализованы для этого конкретного, в отличие от всего вашего приложения.
-
Пользовательский интерфейс. Пользователь подписывается или приглашается использовать ваше приложение и принадлежит одному конкретному клиенту. Собираетесь ли вы сохранить эту учетную запись пользователя в клиентскую базу данных? Если да, см. Масштабируемость для проблемы с работой с этими данными, когда пользователь хочет изменить свой пароль, или вы хотите отправить их по электронной почте. Итак, вы говорите пользователю, чтобы вы знали, в какой базе данных они находятся, чтобы вы могли их найти?
-
Упрощение. У вас есть база данных для каждого клиента и вы хотите просто использовать один. Как вы объедините их все вместе, не нарушая при этом существенных изменений? При использовании автоматических добавочных идентификаторов будут конфликты с первичными ключами; если вы решите просто восстановить ключи, будут заблокированы закладки; внешние ключи через таблицы больше не будут указывать на нужные записи. Ваша целостность данных будет сбрасываться на панораму.
Вы упомянули службы "white label", которые предлагают свой продукт через пользовательские субдомены. Я не знаю, как это работает, но субдомен - это только базовая запись CNAME или в своем DNS файле зоны. Процесс их добавления может быть автоматизирован, а дизайн приложения и конфигурация сервера могут иметь дело с привязкой этих поддоменов к правильным учетным записям и данным. Они всего лишь URL-адреса, поэтому, возможно, на бэкэнд приложение не различает:
http://client.example.com
http://example.com/client
В целом, вы можете решить, что все эти проблемы - это то, что вы можете и хотели бы иметь. Однако имейте в виду, что, делая это, вы можете стрелять в ногу, и вы можете получить гораздо больше от разработки хорошо продуманной схемы единой базы данных и хорошо отформатированного интерфейса.
* @xQbert упоминает очень реальную выгоду от масштабируемости с несколькими базами данных. Я внесла поправки в этот ответ, чтобы уточнить, что меня больше интересуют другие аспекты.