Управление изменениями базы данных с помощью руки генерировало [закрытые] сценарии
Повышенные брови должны сказать Вам достаточно прекращать делать его. Вы не пишете код для компилятора, Вы пишете его для своих коллег - программистов сначала и затем для компилятора. Даже если компиляторы работают, удивление других людей не то, что Вы хотите - побитовые операторы для битовых операций не для bools.
я предполагаю, что Вы также едите яблоки с ветвлением? Это работает, но это удивляет людей, таким образом, лучше не сделать это.
7 ответов
Хорошо, мне не понравился ни один из вариантов, которые я там нашел. Я нашел несколько хороших инструментов для создания скриптов, но ничего, что могло бы отслеживать версию в базе данных и запускать новые скрипты. Как бы то ни было, я пошел дальше и запустил свой собственный инструмент с открытым исходным кодом, чтобы выполнить свою работу. Если вы хотите использовать его, вы можете загрузить его с CodePlex, он называется KissDB . Я также опубликовал сообщение об этом в своем блоге blog.RunXc
Если у вас есть все сценарии для данной версии в папке, вы можете запустить это как пакетный файл, если поместите его в этой папке:
for %%X in (*.SQL) do SQLCMD -S <SERVER_NAME> -d <DATABASE_NAME> -E -I -i "%%X" >> ResultBatch.txt
Извините, я не помню, откуда я это взял, иначе я бы отдал должное.
Если вы хотите написать все сценарии самостоятельно, вы можете воспользоваться утилитой SQL Server 2005 TableDiff , которая даст вам большую гибкость. Некоторые примеры использования можно найти здесь
Это сложная задача, простая и понятная. Инструменты, упомянутые в других ответах, определенно могут помочь, но вам все еще предстоит многое сделать самому.
На самом деле у меня есть таблица в моей схеме, в которой хранится идентификатор для каждого сценария изменения (который соответствует номеру дела в моей проблеме / система отслеживания ошибок). В конце каждого сценария изменения я вставляю идентификатор в эту таблицу. У меня есть отдельный скрипт, который проверяет, что было сделано в любом конкретном экземпляре базы данных. Было бы возможно автоматизировать запуск каждого из сценариев, которые еще не были запущены, но мне нравится запускать сценарии изменений вручную на случай, если что-то пойдет не так.
Откат может быть почти невозможным, тем более что для многих изменений схемы требуется какое-то миграции данных. Я обнаружил, что лучший способ внесения любых изменений в схему - сделать их обратно совместимыми. Никогда не переименовывайте столбец или таблицу (по крайней мере, сначала). Добавляйте только вещи и делайте все новые добавления допускающими значение NULL. Скрипт отката просто удаляет новый материал, если вы понимаете, что что-то не так. Конечно, у вас останутся старые неиспользуемые столбцы и таблицы, поэтому вы пишете второй сценарий, который запускается после того, как ваш текущий выпуск считается стабильным, что избавляет от старого материала.
Вы уже смотрели Open DBDiff ? Это может быть хорошим местом для начала.
если вы передумаете об открытом исходном коде, Red Gate's SQL Compare - это путь для ИМО.
На SourceForge есть довольно интересный проект под названием SQLRunner - это C #, это .NET, он прошел "пре-альфа" :-)
Я не Сам использовал, но все равно - выглядит неплохо, ИМХО.
Marc