сценарий - внешние параметры/настройки

Question

Вопроса Резюме:

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

Предпосылки/Требования:

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

• План - на данный момент - это реализовать простой инструмент командной строки (в .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 (или, по крайней мере, как «действительный», как он есть на данный момент), но все же нарушает инструмент развертывания. Отсутствие каких-либо побегов, например, касается. И параметры шаблона в литеральных строках заставляют меня сканировать скин.

Другие возможности, которые я Рассмотренные:

• Construct динамический SQL сценарий, который будет выполняться с sp_executesql.Это обеспечило бы использование истинных параметров в отличие от наивного шаблона, но сделало бы сценарий невероятно громоздким для написания, тестирования и поддержки, особенно если мы когда-либо решаем взять новую базовую линию (что мы могли бы - это большая база данных) ,

• Используйте параметры шаблонов SSMS. Это отлично отделяет его от инструмента развертывания, но также затрудняет интеграцию с инструментом развертывания - как-то связать его с SSMS.

• Внедрение сценария в инструмент развертывания. Таким образом, никто не может обходиться с ним, и ясно, что сценарий - это просто шаблон, который нужно обработать. Значения по умолчанию могут быть внедрены где-то «близко» к скрипту. Основным, огромным недостатком является то, что инструмент развертывания становится специфичным для приложения и может потребовать изменения кода для чего-то, что действительно не требует изменения кода.

• Сгенерировать весь сценарий динамически с внешнего, доступного для человека файла, такого как YAML. Сначала эта идея показалась очень элегантной, но в конце концов она начала погружаться в то, что я мог бы изобретать колесо. Все, что нужно сделать в базе данных, должно быть включено в базу данных, так ли это действительно дает какое-либо преимущество перед изменением вручную простого сценария SQL или даже создания базы данных вручную через SSMS?

Ни один из этих вариантов не кажется совершенно правильным. То, что я хочу, это то, что независимое (так же, как код теоретически не зависит от среды, которую вы используете для его создания), но также и читаемый (нет «SQL внутри SQL») и самоочевидный (четко определяет, что необходимы настройки и какие могут быть хорошие значения по умолчанию).

Есть ли какие-либо методы, которые достигнут всего, чего я пытаюсь достичь? Или я просто слишком разборчива или неправильно смотрю на проблему?

(PS Я не в настоящее время ищет коммерческого, автономный, 3-сторонних разработчиков, которые будут выполнять эту задачу для меня. «Теперь у меня есть две проблемы.»)

Answer 1

Мы решили аналогичную проблему, создав скрипт, который может использовать параметры sqlcmd. Что-то вроде:

:setvar filename somefile.ext 
:setvar version 1 
:on error exit 

print 'This is version $(version) on $(filename)' 
-- the rest of the actual script 

Это может быть запущено через командную строку или SSMS. В конце концов мы создали инструмент, который мог бы прочитать файл и заменить переменные с тем же синтаксисом.

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

Answer 2

я бы, вероятно, либо использовать этот сценарий как встроенный шаблон в инструменте командной строки; получите минимальную требуемую информацию (для замены заполнителей - DBName и LogFileSize, другие параметры, такие как имена файловых групп, могут быть выведены из DBName, например FG_ {DBName} _PRIMARY для основной файловой группы) из параметров командной строки. Используйте текстовый поиск/замену, чтобы заполнить пробелы, а затем выполните это для SQL Server, на который вы хотите развернуть его.

E.g. что-то вроде:

CreateDB -server:(local) -dbname:MyTestDB -logsize:50 (as in 50 MB) 

Или: использования SMO (объекты управления SQL Server) для создания базы данных. Вам в основном нужна одна и та же информация (имя БД, размер файла журнала), и вы можете программно создавать базу данных и ее макет - не требуется сценарий T-SQL.

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

• первичной файловой группа: не оставил в покое только с системным каталогом - ничего еще
• DATA файловой группы: пометить как DEFAULT используется для таблиц
• INDEX файловой группы: для индексов

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

Answer 3

Вы считаете, что используете SQLCMD scripts и SQLCMD utility вместо того, чтобы писать собственный интерфейс командной строки или, возможно, писать свои собственные и просто обертывать функциональность SQLCMD? Естественно, это предполагает, что вы хотите только поддерживать SQL 2005 и выше. Я делал это в прошлом несколькими способами (например, используя простой пакетный файл с параметрами/параметрами, которые обертывают SQLCMD, используя более обширный подход, заключенный в код, который, к сожалению, был VB 6.0 в то время и т. Д.), ,

Если вы берете маршрут обертывания собственным кодом, возможно, захотите также рассмотреть возможность использования powershell (в настоящее время я тоже об этом думаю). Sql Server теперь включает в себя пользовательские поставщики Powershell и расширения для таких функций, как функциональность SMO, выполнение кода, управление и т. Д., Которые можно естественным образом и легко расширить для интеграции SQLCMD и функциональных возможностей SQL.

Учитывая то, что вы пытаетесь сделать, выгоды с SQLCMD (и Sqlcmd скриптов), похоже, вписывались вещи:

• Сценарии все еще действителен для использования/интерпретация/интеграции с SSMS и другой IDE
• Существует несколько вариантов значений по умолчанию, хотя ничто действительно не интегрировано в сами сценарии (переменные среды, параметры командной строки и т. Д.). Кроме того, вы можете захотеть потянуть свои значения по умолчанию для местоположений файлов и групп из заранее определенного местоположения на сервере/экземпляре, на котором вы работаете (например, модели или мастера или tempdb).
• Менее надуманный в том смысле, что в настоящее время IDE, которые поддерживают SQLCMD бы бросать исключения в режиме SQLCMD для комбинаций неопределенных переменного/значения

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