Лучшие практики для написания сценариев SQL для развертывания

Question

Мне было интересно, каковы лучшие практики для написания сценариев SQL для настройки баз данных для производства и / или разработки, например:

• Должен ли я включить оператор CREATE DATABASE?
• Должен ли я создавать пользователей для базы данных в том же сценарии?
• Правильно ли отключать проверку FK перед выполнением тела скрипта?
• Могу ли я включить в транзакцию скрипт дырки?
• Лучше генерировать 1 скрипт на базу данныхчем один сценарий для всех из них?

Спасибо!

Answer 1

Сложно ответить на проблему с вашим вопросом, поскольку она зависит от того, как сценарии используются в том, чего вы пытаетесь достичь. Вы также не говорите, какой сервер БД вы используете, поскольку есть инструменты, которые могут упростить некоторые задачи.

Приводя свои пункты в порядок, вот несколько советов, которые, вероятно, будут сильно отличаться от всех остальных :)

• Должен ли я включить базу данных CREATE утверждение?

Какую альтернативу вы думаете использовать? Если ваш вопрос заключается в том, следует ли поместить оператор CREATE DATABASE в тот же сценарий, что и при создании таблицы, это зависит. При разработке БД я использую отдельный скрипт создания БД, так как у меня есть скрипт для удаления всех объектов, поэтому мне не нужно снова создавать базу данных.

• Должен ли я создавать пользователей для базы данных в том же сценарии?

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

• Правильно ли отключать проверку FK перед выполнением тела скрипта?

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

• Могу ли я включить весь сценарий в транзакцию?

Да, вы можете, но опять же, это зависит от типа скрипта, который вы запускаете. Если вы импортируете данные после перестройки БД, тогда весь импорт должен сработать или потерпеть неудачу. Тем не менее, ваш файл транзакций будет огромным во время импорта.

• Лучше ли генерировать 1 скрипт для каждой базы данных, чем один скрипт для всех из них?

Опять же, в целях обслуживания, вероятно, лучше хранить их отдельно.

Answer 2

Это, вероятно, зависит от того, какая база данных и как она используется и развернута. Я занимаюсь разработкой стандартного n-уровневого приложения, которое развернуто на многих сайтах клиентов.

1. Я не добавляю оператор CREATE DATABASE в скрипт. Создание базы данных является частью сценария установки, который позволяет пользователю выбрать сервер, имя базы данных и параметры сортировки

2. У меня нет сведений о пользователях на сайтах моих клиентов, поэтому я не добавляю операторы создания пользователей, а единственный пользователь, которому необходим доступ к базе данных, - это пользователь, выполняющий приложение со средней шиной.

3. Я не отключаю проверки FK. Они нужны мне для защиты целостности базы данных, даже если это я написал сценарии тела. Я использую FK, чтобы зафиксировать мои ошибки.

4. Я не включаю весь скрипт в одну транзакцию. Я требую от пользователей сделать резервную копию базы данных, прежде чем они запустят какие-либо сценарии обновления базы данных. Для создания новой базы данных защищать нечего, поэтому выполнение транзакции не требуется. Для апгрейдов иногда происходят значительные изменения в БД. Пару лет назад мы перешли с varchar на nvarchar примерно за 250 таблиц. Не то, что вы хотели бы сделать в одной транзакции.

5. Я бы порекомендовал вам создать один сценарий для каждой базы данных и сценарии контроля версий отдельно.

Answer 3

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

Я считаю, что лучше всего создавать все изменения базы данных с помощью сценариев, которые хранятся в системе контроля версий в соответствии с версией. Поэтому, если клиент новый, вы запускаете сценарии создания версии 1.0, а затем применяете все остальные версии по порядку. Если клиент просто обновляется с версии 1.2 до версии 1.3, то вы запускаете только сценарии в репозитории исходного кода версии 1.3. Это также включает в себя сценарии для заполнения или добавления записей в таблицы поиска.

Для транзакций вы можете разбить их на несколько частей, чтобы не оставлять базу данных prod заблокированной в одной транзакции.

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

Answer 4

Стоит ли включать оператор CREATE DATABASE?
Должен ли я создавать пользователей для базы данных в том же сценарии?

Это зависит от вашей СУБД и вашего клиента.

В среде Oracle вам, вероятно, никогда не разрешат делать такие вещи (в основном потому, что в мире Oracle «база данных» - это нечто совершенно иное, чем, например, в мире PostgreSQL или MySQL).

Иногда у клиента будет администратор базы данных, который не позволит вам создавать базы данных (или схемы, или пользователей - в зависимости от используемой СУБД). Таким образом, вам нужно будет предоставить эту информацию администратору базы данных, чтобы он / она подготовили среду для вашего сценария.

Могу ли я включить дырочный скрипт в транзакцию?

Это полностью зависит от СУБД, которую вы используете.

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

Для заполнения таблиц данными я бы определенно попытался сделать это за одну транзакцию, но опять же, это зависит от вашей СУБД.

Некоторые СУБД работают быстрее, если вы делаете коммит только один раз или очень редко (Oracle и PostgreSQL попадают в эту категорию), но замедляются, если вы делаете коммит чаще.

Другие СУБД справляются с меньшими, но большими транзакциями лучше и замедляются, если транзакции становятся слишком большими (SQL Server и MySQL имеют тенденцию падать в этом направлении)

Answer 5

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

При развертывании вы можете объединить изменения для каждого выпуска в один скрипт. В этом вам помогут такие инструменты, как сравнение с Red Gate SQL или Visual Studio Team System.

Answer 6

Прямые ответы, пожалуйста, спросите, если вам нужно расширить в любой точке

* Should I include the CREATE DATABASE statement?

Обычно я бы включил его, поскольку вы создаете базу данных и владеете ею.

* Should I create users for the database in the same script?

Это также хорошая идея, особенно если ваше приложение использует определенных пользователей.

* Is correct to disable FK check before executing the body of the script?

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

* May I include the hole script in a transaction?

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

* Is better to generate 1 script per database than one script for all of them?

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