Strategy "one database with client separator" vs. "each one database"

Question

PostgreSQL

Кто-то сталкивался с задачей создать многопользовательское решение с многочисленными пользовательскими данными? Что бы не 2-3 таблицы, как в интернет-магазинах, а от 10 и значительно выше.

Первое что приходит в голову — это добавить дополнительное индексируемое поле во все таблицы с айдишником пользователя. Но некоторые из потенциальных клиентов хотят, что бы СУБД с их конфедициальными данными находилось на их площадках, а на нашем сервере происходила исключительно обработка. В связи с этим появилась мысль, а не попробовать ли сразу разносить разных клиентов по разным базам? Я немного попереваривал в голове эту мысль и сформировал следующие преимущества и недостатки.

Плюсы второго решения:
1) Легкость в администрировании: легко выдаются тестовые аккаунты и так же легко удаляются; можно обеспечить договорной уровень бекапирования данных (с выдачей клиенту или локальным хранением) и восстановить по требованию архив за любую отметку времени. Все это делается в разы труднее, если хранить все данные в одном хранилище.
2) Возможность создания и управления базами, которые расположены на различных серверах (в том числе и на клиентском).

Минусы второго решения:
1) Сложность поддержки и доработки общей системы — вместо одной базы придется дорабатывать целую ферму баз
2) В случае локального размещения данных у клиентов нужно с ними еще договариваться про их обновление
3) При работе будущей системы вместо одного (или пачки, в случае балансировки) коннекшена к базе, через который можно получать данные различных клиентов, нужно будет поддерживать для каждого пользовательского подключения отдельное соединение.

При сравнении двух подходов явно видно противостояние легкости разработки против легкости поддержки.

Меня интересуют в первую очередь мнение тех, кто подобные системы уже делал.
К каким проектным решениям вы пришли? На какие грабли наступили при уходе в эксплуатацию?

P.S. В качестве СУБД выбрана PostgreSQL, так как под нее заточена часть функционала, но интересует мнение и по другим реляционным БД.

P.S.S. Пересекающиеся данные между различными компаниями отсутствуют. Нет необходимости делать консолидацию. Вся общая справочная информация находится в ином сервисе.

Answer 1

:) Напились вдоволь
Кстати вот вам еще идейка, мы в итоге сделали следующим образом:
1) У себя «на кухне» готовим для клиента виртуалочку, паролим ее — выворачивая наружу интерфейс БД.
(Но насколько я понял базы у вас тяжелые, потому могут быть траблы с производительностью)
2) Отдаем сию виртуалочку клиенту, он ее у себя запускает и наш софт конектится к ней как к сетевой БД.
Одминов в свою очередь просим по возможности нас на нее пустить по ssh
(Здесь поджидает проблема если у клиента говеная локалка или админь — упырь, в последнем случае все очень плохо
вот таких мы пускаем к себе на виртуалочки предусмотрительно развернутые на хостинге поближе к клиенту)
PROFIT!!! — убиваем несколько проблем:
1) Клиент не причастен к конфигурации не то чтобы БД, но и системы с необходимой экосистемой
2) Развертывание — проще простого.
3) Разбор полетов можно производить на Time Stamp виртуалки в реальном окружении. (Так как не всегда БД является источником проблем)
4) Миграция тоже очень проста, мы потихонечку уговариваем клиентов таки перебираться «в облака» (у кого нет проблем с интернетом)

Answer 2

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

Answer 3

Еще вариант, перекликающийся с первым ответом, оставить одну базу, но разнести таблицы клиентов по разным схемам. Избегается столпотворение таблиц в одной схеме, при этом довольно легко все обновлять и давать доступ каждому клиенту только к его данным. Админится только 1 БД, что тоже, в данном случае, облегчает жизнь.
Минусы как и при разных базах — если выходит исправление/обновление вместо единого набора таблиц, придется пройти и пропатчить каждую из них в каждой схеме.

Answer 4

Очень много других факторов которые так же влияют на принятие подобного рода решений,
например потянет ли ваше железо кучу пользователей, таким образом чтобы им было комфортно работать, стабильный ли у Вас / у них коннект.
А если их число удвоить например (я про пользователей)
У нас была отчасти похожая задача, в итоге у клиента свой БД — но мы ее постоянно реплицируем к себе, кстати так и обновляем свою обновленную версию разворачивая назад. Естественно на это время работа с базой на стороне клиента заблокирована архитектурно приложением до завершения.
Да и что касается обновления то рано или поздно вам все равно необходимо будет автоматизировать процесс.
Перед нами стояли проблемы и железа и коннекта и его скорости, не знаю как у Вас.
PS: Личный совет, если уж и будете БД у клиентов держать, то не подпускайте их IT-долбоящеров к обновлению или конфигурированию.