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