SQL Server 2008: N небольших баз данных VS 1, база данных с N схемами

Question

У меня есть сервер баз данных с несколькими основными базами данных и несколькими десятками небольших.

Эти небольшие базы данных являются своего рода промежуточными / промежуточными базами данных для импорта данных из различных источников в основную базу данных. Импорт данных - ежедневная задача. Все они очень похожи по структуре, так как реализация этих импортов данных похожа, поэтому в основном они имеют таблицы конфигурации, которые определяют отображение, преобразования и т. Д., И таблицы данных, которые содержат результаты импорта.

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

Я только что перенес всю серверную среду на SQL Server 2008, и теперь у меня есть время для очистки / рефакторинга, и я собираюсь объединить все базы данных импорта данных в одну базу данных и использовать database schema для отделить их.

Вопрос-0: Есть другие идеи для описанной ситуации?

Вопрос-1: Должен ли я перейти с separate database на separate schema?

Вопрос-2: !!!: Любая хитрая вещь, с которой нужно быть осторожным в реализации database schema?

---

Правка-1: выделил вопрос-2 как самый «оставшийся без ответа» в настоящее время.

Answer 1

В вашем случае я бы, вероятно, объединил базы данных в одну. На самом деле я не вижу причин для их разделения, и объединение их уменьшит объем работы, которую вы должны выполнить для поддержки резервного копирования и т. Д. Если вы импортировали данные из источника данных один раз, а затем никогда не использовали промежуточные таблицы, Я мог видеть причину для создания отдельных баз данных для обработки преобразования данных. Поскольку вы используете эти таблицы на постоянной основе, я бы предпочел хранить их вместе, так что мне нужно всего лишь перейти в одно место, чтобы найти полное конечное состояние производственных данных и состояний загрузки данных.

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

Answer 2

Поскольку база данных является единицей ссылочной целостности и резервного копирования, если вы вводите большие объемы данных для промежуточного хранения, для которых не требуется резервное копирование по одному и тому же расписанию, проще всего хранить его в отдельной БД .

Вы можете использовать одну БД с несколькими группами файлов и разными резервными копиями, но это потребует гораздо большего дизайна.

Основными факторами, от которых это будет зависеть, являются: модель восстановления, цели резервного копирования, модели использования и объем усилий по разработке и поддержке дизайна вашей файловой группы.

Answer 3

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

Answer 4

Все предыдущие ответы работают для меня, особенно ваш комментарий о выборочном объединении баз данных - если некоторые из них очень заняты, очень велики или обрабатывают конфиденциальные данные, вы можете захотеть хранить их отдельно или в отдельных группах. Это упростит настройку резервного копирования / восстановления и распределения дисков / дисков (предоставьте занятым их собственный набор шпинделей).

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

Answer 5

Я бы поместил все ваши промежуточные таблицы импорта в одну базу данных отдельно от обычной производственной базы данных, поскольку потребности в резервном копировании могут сильно отличаться. Эта база данных также должна содержать такие вещи, как управление конфигурацией для пакетов служб SSIS, любые таблицы журналов, любые таблицы метаданных импорта (мы отслеживаем каждый запуск импорта и статус этого запуска, а также несколько других вещей об импорте, таких как имя файла, нормальный размер файла и т. д. Полезно для исследования проблем и добавления проверок к обработке. Мы используем схему, выполняемую клиентом, а затем дополнительную схему для объектов, реализуемых в процессе импорта / экспорта (журналы, метаданные и др.)