Я работал над новым проектом, который требует использования 7 баз данных, утверждая, что производительность, стабильность, оптимизация легче реализовать.
Хотя я не согласен, у меня возникают проблемы со сбором хороших аргументов для использования одной базы данных (разбиение таблиц на логические домены).
Пока что у меня есть один аргумент - целостность данных (я не могу использовать внешние ключи между базами данных).
Каковы хорошие плюсы / минусы для использования одной или нескольких баз данных?
[Резюме до сих пор]
Аргументы против нескольких баз данных:
Потеря целостности данных (нельзя использовать внешние ключи над базами данных)
Потеря восстановления целостности
Получение сложности (дБ пользователей / ролей)
Сервер / база данных с малыми коэффициентами упадет
Решения:
Используйте схемы для разделения доменов.
POC: Используйте фиктивные данные, чтобы доказать точку в планах выполнения 7/1 дБ
Ответы:
Ни производительность, ни стабильность, ни оптимизация не соответствуют действительности. У кого-нибудь есть твердый аргумент или справочная статья, почему это было бы правдой?
Ресурсы не выделяются для базы данных: экземпляр SQL Server балансирует ресурсы, поэтому нет никакой разницы
Ты проиграл:
Вы получаете сложность:
Параметры:
источник
Хорошие причины для создания отдельных баз данных - поддержка различных требований к доступности или упрощение администрирования. Например, если для ваших баз данных требуется совсем другое расписание резервного копирования или разные модели восстановления. Другой причиной может быть, если вы захотите запустить их в разных экземплярах.
Нет возможности оптимизировать производительность для нескольких баз данных, чего нельзя достичь и для одной базы данных. Можете ли вы рассказать подробнее о том, что вы подразумеваете под «производительностью, стабильностью, оптимизацией»?
источник
Если вы разбиваете данные по логическим доменам, вы всегда можете посмотреть на использование схем в SQL2008 (отходя от значения по умолчанию для dbo.), Но даже это болезненно и может вызвать проблемы с OR / M, которые не ожидают схема
Я был в состоянии сопоставления данных из более чем одной базы данных, и это больно и далеко от высокой производительности. Вы заканчиваете кэшированием данных или, по крайней мере, используете приемы для поддержания скорости.
В качестве теста соберите 7 фиктивных баз данных. Создайте запрос, который требует данных одновременно от всех 7 или хотя бы большого числа из них.
Тогда сравните планы выполнения! Я думаю, что вы выиграете ваше дело прямо здесь.
источник
Мысленный эксперимент: вместо того, чтобы делить вашу базу данных на семь частей, вместо этого разбейте ее на 7 000 частей. Какова вероятность того, что аппаратный сбой повлияет на ваше приложение? Если существует вероятность того, что какой-либо конкретный сервер умрет в определенный день, с вероятностью 0,1%, будут ли ваши шансы лучше или хуже того, что на вас повлияет аппаратный сбой при увеличении числа машин, от которых вы зависите?
Я думаю, что важно разделить понятие «база данных» на две части: схема и данные в зависимости от аппаратного обеспечения, которое используется для обслуживания данных.
Распределение базы данных по нескольким машинам не приносит пользы по многим причинам, объясненным другими ответами в этом разделе.
Если вы собираетесь использовать несколько компьютеров для обеспечения надежности и повышения производительности, возможно, вы сможете структурировать их так, чтобы у вас был главный сервер с несколькими компьютерами с горячим / горячим резервированием, которые также можно использовать для распределения запросов между ними. Таким образом, если какой-либо компьютер выходит из строя, вы не теряете данные, и в худшем случае вам придется перезапустить запрос. Конечно, это сложнее, чем это, но основы применимы.
источник
Я согласен с одной БД и использую вместо нее параметры файла и схемы.
Есть крайние случаи, когда имеет смысл разделение на несколько частей.
Конфигурация среды приложения (dev, test, prod), такая как FTP-серверы, пути к файлам экспорта и т. Д., Вещи, которые вы хотите хранить на сервере, а не перезаписывать при восстановлении.
Также как способ изолировать специфичные для клиента изменения процедур.
Но это проблемы поддержки, а не производительности.
источник