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

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

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

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

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

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

потом

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

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

@Адам

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

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

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

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

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

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

@Justin

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

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

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

Потратьте время на написание универсального сценария «удаления всех ограничений», чтобы вам не приходилось его поддерживать.

Курсор на следующие операторы делает свое дело.

Select * From Information_Schema.Table_Constraints 

Select * From Information_Schema.Referential_Constraints

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

Мой бывший работодатель использовал схему, в которой вся таблица DDL находилась в одном файле (хранится в синтаксисе Oracle), указывает в другом, ограничения в третьем и статические данные в четвертом. Параллельно с этим был сохранен сценарий изменения (опять же в Oracle). Преобразование в SQL было ручным. Это был беспорядок. На самом деле я написал удобный инструмент, который конвертирует Oracle DDL в SQL Server (он работал в 99,9% случаев).

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