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

Question

В настоящее время я создаю master ddl для нашей базы данных. Исторически мы использовали резервное копирование / восстановление для версии нашей базы данных и не поддерживали никакие ddl-скрипты. Схема довольно большая.

Мое нынешнее мышление:

• Разбить скрипт на части (возможно, в отдельных скриптах):

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

• Каждый сценарий будет вызываться главным сценарием.

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

Любой другой совет?

Редактировать: Также, если кто-то знает хорошие инструменты для автоматизации части процесса, мы используем MS SQL 2000 (старый, я знаю).

Answer 1

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

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

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

Таким образом, заказ будет

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

Тогда

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

@ Адам

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

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

Answer 5

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

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

Select * From Information_Schema.Table_Constraints 

Select * From Information_Schema.Referential_Constraints

Answer 6

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

@ Джастин

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

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

Answer 7

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

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

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