Как мне организовать мой мастер ddl скрипт

Я думаю, что основная идея хороша.

Самое приятное в том, чтобы сначала построить все таблицы, а затем построить все ограничения, заключается в том, что таблицы могут быть созданы в любом порядке. Когда я сделал это, у меня был один файл на таблицу, который я поместил в каталог с именем "Tables", а затем скрипт, который выполнил все файлы в этом каталоге. Точно так же у меня была папка для скриптов ограничений (которые тоже делали внешний ключ и индексы), которые выполнялись после построения таблиц.

Я бы разделил сборку триггеров и хранимых процедур и запустил эти последние. Дело в том, что они могут быть запущены и повторно запущены в базе данных, не затрагивая данные. Это означает, что вы можете обращаться с ними так же, как с обычным кодом. Вы должны включать операторы "if exists...drop" в начале каждого сценария триггера и процедуры, чтобы сделать их повторно выполняемыми.

Так что порядок будет таким

1. создание таблиц
2. добавление индексов
3. добавить ограничения

Затем

4. добавить триггеры
5. добавление хранимых процедур

В моем текущем проекте мы используем MSBuild для запуска сценариев. Есть несколько целевых расширений , которые вы можете получить для него, которые позволяют вызывать sql скрипты. В прошлом я использовал perl, который тоже был хорош (и batch files...which я бы не рекомендовал - они слишком ограничены).

есть аккуратные инструменты, которые будут перебирать весь сервер sql и извлекать все таблицы, представления, сохраненные процедуры и определения UDF в локальную файловую систему в виде SQL скриптов (текстовых файлов). Я использовал это с 2005 и 2008 годами, хотя не уверен, как это будет работать с 2000 годом. Проверить http://www.antipodeansoftware.com/Home/Products

То, что у вас там есть, кажется довольно хорошим. Моя компания иногда, для достаточно больших баз данных, разбила его еще дальше, возможно, до уровня отдельного объекта. Таким образом, каждый table/index/... имеет свой собственный файл. Может быть полезным, может быть излишним. Все зависит от того, как вы его используете.

@Justin

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

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

Потратьте время на написание универсального сценария "drop all constraints", так что вам не придется его поддерживать.

Курсор над следующими инструкциями делает трюк.

Select * From Information_Schema.Table_Constraints 

Select * From Information_Schema.Referential_Constraints

@Adam

Или как насчет просто по домену-полезная группировка связанных таблиц в одном файле, но отдельно от rest?

Единственная проблема заключается в том, что некоторые домены (в этой несколько устаревшей системе) тесно связаны. Кроме того, вы должны поддерживать зависимости между различными подскриптами.

Если вы ищете инструмент автоматизации, я часто работал с EMS SQLManager, который позволяет автоматически генерировать скрипт ddl из базы данных.

Вставки данных в справочные таблицы могут быть обязательными перед вводом базы данных в эксплуатацию. Это можно даже рассматривать как часть сценария ddl. EMS также может создавать сценарии для вставки данных из существующих баз данных.

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

Ранее я организовал свой код DDL по одному файлу на сущность и сделал инструмент, который объединил его в один скрипт DDL.

Мой бывший работодатель использовал схему, в которой вся таблица DDL была в одном файле (хранится в синтаксисе oracle), индексы в другом, ограничения в третьем и статические данные в четвертом. Вместе с этим в paralell был сохранен сценарий изменения (снова в Oracle). Преобразование в SQL было произведено вручную. Это был настоящий бардак. Я действительно написал удобный инструмент, который преобразует Oracle DDL в SQL сервер (он работал 99.9% в то время).

Недавно я перешел на использование командной системы Visual Studio для специалистов по базам данных . До сих пор он работает нормально, но есть некоторые сбои, если вы используете функции CLR в базе данных.