В настоящее время я создаю master ddl для нашей базы данных. Исторически мы использовали резервное копирование / восстановление для версии нашей базы данных и не поддерживали никакие ddl-скрипты. Схема довольно большая.
Мое нынешнее мышление:
Разбить скрипт на части (возможно, на отдельные скрипты):
- создание таблицы
- добавить индексы
- добавить триггеры
- добавить ограничения
Каждый сценарий вызывается основным сценарием.
- Мне может понадобиться скрипт для временного удаления ограничений для тестирования
- В схеме могут быть потерянные таблицы, я планирую идентифицировать подозрительные таблицы.
Любой другой совет?
Изменить: Также, если кто-то знает хорошие инструменты для автоматизации части процесса, мы используем MS SQL 2000 (старый, я знаю).
То, что у вас там, кажется довольно хорошим. Моя компания иногда, для достаточно больших баз данных, разбивала ее еще дальше, возможно, на уровне отдельных объектов. Таким образом, каждая таблица / индекс / ... имеет свой собственный файл. Может быть полезным, может быть излишним. Действительно зависит от того, как вы его используете.
@Justin
По доменам в основном всегда достаточно. Я согласен с тем, что при таком подходе необходимо иметь дело с некоторыми сложностями, но с этим должно быть достаточно легко справиться.
Я думаю, что этот метод обеспечивает немного больше разделения (что в большой базе данных вам понравится), но при этом делает себя довольно управляемым. Мы также пишем сценарии Perl, которые выполняют большую часть обработки этих файлов DDL, так что это может быть хорошим способом справиться с этим.
Потратьте время на написание общего сценария «отбросьте все ограничения», чтобы вам не пришлось его поддерживать.
Курсор над следующими утверждениями делает свое дело.
Select * From Information_Schema.Table_Constraints
Select * From Information_Schema.Referential_Constraints@Адам
Или как насчет домена - полезная группировка связанных таблиц в одном файле, но отдельно от остальных?
Единственная проблема заключается в том, что некоторые домены (в этой несколько устаревшей системе) тесно связаны между собой. Кроме того, вы должны поддерживать зависимости между вашими различными сценариями.
Ранее я организовал свой код DDL, упорядоченный по одному файлу на сущность, и создал инструмент, который объединил его в один сценарий DDL.
Мой бывший работодатель использовал схему, в которой вся таблица DDL была в одном файле (хранится в синтаксисе оракула), указывает на другой, ограничения на третий и статические данные на четвертый. Сценарий изменения был сохранен в паре с этим (снова в Oracle). Преобразование в SQL было ручным. Это был беспорядок. На самом деле я написал удобный инструмент, который преобразует Oracle DDL в SQL Server (он работал 99,9% времени).
Недавно я перешел на использование Visual Studio Team System для специалистов по базам данных . Пока это работает нормально, но есть некоторые глюки, если вы используете функции CLR в базе данных.
Я думаю, что основная идея хороша.
Хорошая вещь о построении всех таблиц сначала и затем о создании всех ограничений, состоит в том, что таблицы могут быть созданы в любом порядке. Когда я сделал это, у меня был один файл на таблицу, который я поместил в каталог «Таблицы», а затем скрипт, который выполнил все файлы в этом каталоге. Точно так же у меня была папка для скриптов ограничений (которые также выполняли внешний ключ и индексы), которые выполнялись после создания таблиц.
Я бы отделил сборку триггеров и хранимых процедур и запустил их последними. Дело в том, что их можно запускать и повторно запускать в базе данных, не затрагивая данные. Это означает, что вы можете обращаться с ними как с обычным кодом. Вы должны включать операторы if if Существует ... drop в начале каждого сценария триггера и процедуры, чтобы сделать их повторно запускаемыми.
Так что порядок будет
- создание таблицы
- добавить индексы
- добавить ограничения
потом
- добавить триггеры
- добавить хранимые процедуры
В моем текущем проекте мы используем MSBuild для запуска скриптов. Для этого есть несколько расширений , которые позволяют вызывать сценарии sql. В прошлом я использовал Perl, который тоже был в порядке (и командные файлы ... которые я бы не рекомендовал - они слишком ограничены).
Если вы ищете инструмент автоматизации, я часто работал с EMS SQLManager, который позволяет автоматически генерировать сценарий ddl из базы данных.
Вставка данных в справочные таблицы может быть обязательной перед переводом вашей базы данных в оперативный режим. Это может даже рассматриваться как часть сценария ddl. EMS также может генерировать сценарии для вставки данных из существующих баз данных.
Потребность в индексах может быть неправильно оценена на стадии ddl. Вам просто нужно объявить их для первичных / внешних ключей. Другие индексы должны быть созданы позже, как только будут определены представления и запросы.
есть изящные инструменты, которые будут перебирать весь сервер sql и извлекать все таблицы, представления, хранимые процедуры и определения UDF в локальную файловую систему в виде сценариев SQL (текстовые файлы). Я использовал это с 2005 и 2008, не уверен, как это будет работать с 2000, хотя. Проверьте http://www.antipodeansoftware.com/Home/Products