Как следует организовать свой мастер DDL скрипт

голоса
11

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

Мое текущее мышление:

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

    1. создание таблицы
    2. добавить индексы
    3. добавить триггеры
    4. добавить ограничения
  • Каждый скрипт будет вызываться с помощью главного сценария.

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

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

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

Задан 07/08/2008 в 18:18
источник пользователем
На других языках...                            


7 ответов

голоса
3

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

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

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

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

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

затем

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

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

Ответил 11/09/2008 в 18:13
источник пользователем

голоса
1

есть аккуратные инструменты , которые будут перебирать весь сервер SQL и извлекать все таблицы, представления, хранимые proceedures и UDF ОПРЕДЕЛЕНИЯХ в локальной файловой системе в качестве сценариев SQL (текстовые файлы). Я использовал это с 2005 и 2008, не уверен , как это Виль работать с 2000 года , хотя. Проверьте http://www.antipodeansoftware.com/Home/Products

Ответил 29/08/2010 в 07:50
источник пользователем

голоса
1

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

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

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

Ответил 16/09/2008 в 20:48
источник пользователем

голоса
1

@Адам

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

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

Ответил 07/08/2008 в 18:31
источник пользователем

голоса
1

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

Курсор в течение следующих утверждений делает трюк.

Select * From Information_Schema.Table_Constraints 

Select * From Information_Schema.Referential_Constraints
Ответил 07/08/2008 в 18:25
источник пользователем

голоса
1

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

@Justin

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

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

Ответил 07/08/2008 в 18:24
источник пользователем

голоса
0

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

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

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

Ответил 19/08/2008 в 07:19
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more