Плюсы / минусы использования нескольких баз данных против использования одной базы данных

Я работал над новым проектом, который требует использования 7 баз данных, утверждая, что производительность, стабильность, оптимизация легче реализовать.

Хотя я не согласен, у меня возникают проблемы со сбором хороших аргументов для использования одной базы данных (разбиение таблиц на логические домены).

Пока что у меня есть один аргумент - целостность данных (я не могу использовать внешние ключи между базами данных).

Каковы хорошие плюсы / минусы для использования одной или нескольких баз данных?

[Резюме до сих пор]

Аргументы против нескольких баз данных:

• Потеря целостности данных (нельзя использовать внешние ключи над базами данных)

• Потеря восстановления целостности

• Получение сложности (дБ пользователей / ролей)

• Сервер / база данных с малыми коэффициентами упадет

Решения:

• Используйте схемы для разделения доменов.

• POC: Используйте фиктивные данные, чтобы доказать точку в планах выполнения 7/1 дБ

Ни производительность, ни стабильность, ни оптимизация не соответствуют действительности. У кого-нибудь есть твердый аргумент или справочная статья, почему это было бы правдой?

Ресурсы не выделяются для базы данных: экземпляр SQL Server балансирует ресурсы, поэтому нет никакой разницы

Ты проиграл:

• целостность данных
• восстановить целостность (данные в DB7 будут позже, чем DB1)

Вы получаете сложность:

• безопасность (пользователи, роли и т. д.) должна быть во всех базах данных
• вы будете иметь некоторые данные, которые не вписываются в 1 базу данных красиво

Параметры:

• разбить базу данных на отдельные диски можно с помощью файловых групп
• использовать схемы для логического разделения данных (на основе другого ответа)

Хорошие причины для создания отдельных баз данных - поддержка различных требований к доступности или упрощение администрирования. Например, если для ваших баз данных требуется совсем другое расписание резервного копирования или разные модели восстановления. Другой причиной может быть, если вы захотите запустить их в разных экземплярах.

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

Если вы разбиваете данные по логическим доменам, вы всегда можете посмотреть на использование схем в SQL2008 (отходя от значения по умолчанию для dbo.), Но даже это болезненно и может вызвать проблемы с OR / M, которые не ожидают схема

Я был в состоянии сопоставления данных из более чем одной базы данных, и это больно и далеко от высокой производительности. Вы заканчиваете кэшированием данных или, по крайней мере, используете приемы для поддержания скорости.

В качестве теста соберите 7 фиктивных баз данных. Создайте запрос, который требует данных одновременно от всех 7 или хотя бы большого числа из них.

Тогда сравните планы выполнения! Я думаю, что вы выиграете ваше дело прямо здесь.

Мысленный эксперимент: вместо того, чтобы делить вашу базу данных на семь частей, вместо этого разбейте ее на 7 000 частей. Какова вероятность того, что аппаратный сбой повлияет на ваше приложение? Если существует вероятность того, что какой-либо конкретный сервер умрет в определенный день, с вероятностью 0,1%, будут ли ваши шансы лучше или хуже того, что на вас повлияет аппаратный сбой при увеличении числа машин, от которых вы зависите?

Я думаю, что важно разделить понятие «база данных» на две части: схема и данные в зависимости от аппаратного обеспечения, которое используется для обслуживания данных.

Распределение базы данных по нескольким машинам не приносит пользы по многим причинам, объясненным другими ответами в этом разделе.

Если вы собираетесь использовать несколько компьютеров для обеспечения надежности и повышения производительности, возможно, вы сможете структурировать их так, чтобы у вас был главный сервер с несколькими компьютерами с горячим / горячим резервированием, которые также можно использовать для распределения запросов между ними. Таким образом, если какой-либо компьютер выходит из строя, вы не теряете данные, и в худшем случае вам придется перезапустить запрос. Конечно, это сложнее, чем это, но основы применимы.

Я согласен с одной БД и использую вместо нее параметры файла и схемы.

Есть крайние случаи, когда имеет смысл разделение на несколько частей.

Конфигурация среды приложения (dev, test, prod), такая как FTP-серверы, пути к файлам экспорта и т. Д., Вещи, которые вы хотите хранить на сервере, а не перезаписывать при восстановлении.

Также как способ изолировать специфичные для клиента изменения процедур.

Но это проблемы поддержки, а не производительности.