Сводка вопроса:
Есть ли лучший способ, чем приведенный ниже, для реализации этапа автоматического создания базы данных при создании базы данных?
Фон / Требования:
Я пытаюсь разработать целостный процесс управления версиями базы данных, используя подход, аналогичный этому . Этот вопрос конкретно касается baseline , который включает физическое создание базы данных.
На данный момент планируется реализовать простой инструмент командной строки (в .NET) для применения как базовых сценариев, так и сценариев изменений. Я хочу, чтобы инструмент был универсальным (у нас есть несколько независимых транзакционных баз данных), и поэтому хотел бы, чтобы все сценарии были внешними, включая создание базы данных.
Среда (ы) тестирования может не быть идеальной копией производства; физические местоположения и размеры файлов могут быть совершенно разными.
Текущая идея: (что я ищу для обратной связи)
В основном система шаблонов. Используйте простой string.Replace в сценарии, подобном следующему:
CREATE DATABASE [{DBNAME}] ON PRIMARY
(
NAME = N'MyDB_Data',
FILENAME = N'{PRIMARYFILENAME}',
SIZE = {PRIMARYSIZE}KB,
MAXSIZE = UNLIMITED,
FILEGROWTH = 5%
),
FILEGROUP [FG_MyDB_Index]
(
NAME = N'MyDB_Index',
FILENAME = N'{INDEXFILENAME}',
SIZE = {INDEXSIZE}KB,
MAXSIZE = UNLIMITED,
FILEGROWTH = 5%
),
-- more filegroups ...
LOG ON
(
NAME = N'MyDB_Log',
FILENAME = N'{LOGFILENAME}',
SIZE = {LOGSIZE}KB,
-- etc.
)
GO
ALTER DATABASE [{DBNAME}] SET COMPATIBILITY_LEVEL = 100
GO
-- more ALTER DATABASE stuff ...
Очевидно, что токены, которые будут заменены, - это {DBNAME} и {LOGFILESIZE}. Значения для них будут взяты из параметров командной строки или, возможно, из внешнего файла.
Проблемы, которые я вижу с этим подходом:
«Сценарий» объявляет себя сценарием T-SQL, но фактически является недействительным T-SQL. Это заставляет вас либо использовать инструмент развертывания, либо выполнять утомительный поиск и замену вручную.
Нет способа запустить его со значениями по умолчанию. Хуже того, он не дает никаких указаний на то, что будет хорошим значением по умолчанию.
Кажется хрупким. Кажется, что можно было бы изменить сценарий таким образом, чтобы он по-прежнему был действительным SQL (или, по крайней мере, таким же «действительным», каким он является в настоящее время), но все еще сломал бы инструмент развертывания. Отсутствие побега, с одной стороны, вызывает беспокойство. А параметры шаблона внутри буквенных строк заставляют мою кожу ползать.
Другие возможности, которые я рассмотрел:
Создание динамического сценария SQL для выполнения с sp_executesql. Это обеспечило бы преимущество истинных параметров по сравнению с наивным шаблоном, но сделало бы сценарий невероятно громоздким при написании, тестировании и обслуживании, особенно если мы когда-нибудь решим взять новую базовую линию (которую мы могли бы - это большая база данных) .
Использовать параметры шаблона SSMS. Это прекрасно отделяет его от инструмента развертывания, но также затрудняет интеграцию с инструментом развертывания - своего рода связывает его с SSMS.
Вставить скрипт в инструмент развертывания. Таким образом, никто не может возиться с этим, и ясно, что скрипт - это просто шаблон, который должен быть обработан. Значения по умолчанию могут быть встроены где-то «близко» к сценарию. Главный огромный недостаток состоит в том, что инструмент развертывания становится специфичным для приложения и может потребовать изменения кода для чего-то, что действительно не должно требовать изменения кода.
Генерирует весь сценарий динамически из внешнего, удобочитаемого человеком файла, такого как YAML. Сначала эта идея казалась очень изящной, но в конце концов она начала тонуть в том, что я мог заново изобретать колесо. Все о базе данных должно быть включено в файл, поэтому действительно ли это дает какое-то преимущество по сравнению с ручным изменением обычного сценария SQL или даже созданием базы данных вручную через SSMS?
Ни один из этих вариантов не кажется совершенно правильным. То, что мне нужно, это то, что не зависит (точно так же, как код теоретически не зависит от среды, которую вы используете для его создания), но также читаем (без «SQL в SQL») и не требует пояснений (четко определяет, какие настройки необходимы и какие могут быть хорошие значения по умолчанию).
Существуют ли методы, которые позволят достичь всего, чего я пытаюсь достичь? Или я просто слишком разборчив или неправильно смотрю на проблему?
(P.S. Я не в настоящее время ищу коммерческие, автономные, сторонние инструменты, которые будут выполнять эту задачу для меня. "Теперь у меня две проблемы.")