Прошу рассудить спор, привести аргументы, ввиду того, что мое мнение как специалиста для заказчика, видимо, ничего не значит или я и не специалист вовсе.
Клиент хочет данных пользователя отельный сервер БД, для истории платежей пользователей отдельную бд, для новостей на сайте отдельную бд и т.д.
В аргументацию приводится: "Переключение бд писать просто", "Так надежней от взломов", "Отказоустойчивость", "Не будет зависаний".
Мои аргументы: х2 удорожание бюджета на разработку, тестирование и поддержание. Бессмысленность всей затеи, так как существуют таблицы (вау), кеширование, параллельный доступ к разным данным, транзакции и блокировки в случае доступа к одним и тем же данным в случае доступа к одним и тем же данным. Причем, блокировки нужны только при изменении данных, а при чтении без проблем параллельные запросы чтения проходят. Беспроблемное выполнение множества запросов в одном соединении. А в случае с несколькими бд, нужно постоянно переключать соединения, что отражается на производительности.
Пользователь сайта редактирует свои данные и они отправляются на модерацию, а пока они не промодерированы отображаются старые данные.
Вот скажите мне, зачем старые данные и новые данные на модерации надо разносить на две базы? Как между двумя удаленными базами строить JOIN запросы, когда это элементарно делается когда данные в разных таблицах?
Может я что то не понимаю. Прошу подтвердить или опровергнуть мои доводы.
СУБД-то какая?
В PostgreSQL проблемы с JOIN'ами таблиц в разных БД будут. В SQL Server таких проблем нет.
Плюс, непонятно чего хочет клиент - каждая база на своём сервере, или один сервер и разные данные в разных базах.
1. Тормозов от переключений БД быть не должно, тк тут вроде достаточно хорошо разделены зоны ответственности:
Новости и платежи никак не связаны и джоины между ними - это что-то странное.
2. Усложнение действительно есть, но если немного с архитектурой поработать - это будет не катастрофично
3. Отражение на производительности - нужно писать бенчмарки
4. Надёжность действительно повысится, тк можно раздельно захостить базу с новостями и базу с платежами, и на платежи выделить больше ресурсов. Так можно сэкономить на обслуживании.
Чтобы ответить конкретно - нужно смотреть в ваш проект, так что вам придётся разбираться с этим самому.
Внесу своих 5 копеек на чаше весов.
Мне кажется рассматривать database - без потребителей этих данных не совсем реалистично.
Я имею в виду, что надо отталкиваться от бизнеса, насколько все эти базы будут жить в согласованности, так как данные бизнеса имеют зависимости.
История платежей пользователей - нуждается наверное в пользователях, они скорее всего хранятся в другом месте(в другой базе). Новости тоже могут иметь зависимости(например комментарии, кого?пользователей) Сложно сказать однозначно в этой ситуации, не вижу всей картины.
Но..В разных базах есть смысл хранить данные, когда есть концептуальное разделение.
Например история платежей - это частный случай, неких выплат. Выплаты можно выделить в отдельный контекст и формализовать.
Надо исходить из предметной области, так как очевидно что ваши конечные пользователи не напрямую из базы читают, есть еще код, который организует это.
Неизвестен масштаб проекта, если всего один разработчик, тогда какое преимущество даст разделение?Оно просто внесет сложность, трату времени и денег. Если бизнес стал развиваться, то скорее это нужда а не философский вопрос.
Еще есть вариант, просто наделать баз в одном монолитном проекте, но такое я еще не видел. Лишать себя связей между таблицами в реляционной базе, должен быть веский повод.
Это может быть связано также с законодательством. Так например хранить персональные данные обязательно на территории РФ; В связи с чем разделение бд на такие данные имеет смысл.
Теоретически разделение на отдельные базы даёт потенциальный резерв масштабирования, т.к. базы могут быть разнесены на разные серверы.
С другой стороны, для работы с взаимосвязанными данными потребуются распределённые транзакции, которые сразу усложнят архитектуру системы и логику приложения, съедят производительность и понизят надёжность.
Клиенту надо предоставить список дополнительных работ с примерными ценами и сроками.
Если он согласен ждать и платить - то ничего не поделаешь.
Плюс список добавляемых рисков тоже не помешает.
Простой
