Заметка которая начиналась как короткий брейн-дамп обратилась в длинную серию статей и во многом благодаря обратной связи и вашим вопросам. В этой публикации я хочу раскрыть некоторые из моих мыслей о контроле изменений объектов, таких как базы данных, вьюшки, хранимые процедуры, функций и триггеры.
Но сначала…
На самом деле я уже не использую триггеры на протяжении нескольких лет. Это не означает, что триггеры бесполезны, но я, как правило, уклоняюсь от их использования. Jon Galloway опубликовал хороший пример того , что можно сделать с триггерами. Во-вторых, мне мусолят глаза хранимые процедуры. Я пришел из WinDNA идеологической школы, в которой вышеупомянутые хранимые процедуры должны использоваться все время. Сегодня я представляю хранимые процедуры в качестве API слоя для базы данных. Это хорошо, если вам нужен слой API на уровне базы данных, но я знаю множество приложений несущих накладные расходы на создание и поддержание этого слоя API в котором они не нуждаются. В этих приложениях хранимые процедуры часто приносят больше усложнений, чем пользы.
Один файл для каждого объекта
Моя стратегия заключается в том чтобы сделать скрипт на каждую вью, хранимую процедуру и функцию в отдельном файле, а затем зафиксировать файлы в системе контроля версий. Если кому-то нужно добавить новую вью, он пишет скрипт вьюшки в файл и фиксирует файл в системе контроля версий. Если кому-то нужно изменить вью он изменяет файл скрипта вьюхи, и коммитит еще раз. Если вам нужно удалить вью из базы данных, просто удалите файл из системы контроля версий. Это относительно простой рабочий процесс.Словно магия происходит, когда разработчик, тестировщик, или установщик обновлений берёт из обновления из системы управления версиями и запускает инструмент, который обновляет свою локальную базу данных. Инструмент использует трёх шаговый процесс:
- Инструмент применяет новые изменения схемы путем сравнения имеющихся файлов изменений схемы к записям SchemaChangeLog в базе данных.
- Инструмент будет УДАЛЯТЬ все хранимые процедуры, вьюшки и функции в базе данных.
- Инструмент будет запускать все скрипты, необходимые для добавления вьюх, хранимых процедуры и функции обратно в базу данных.
Чего-чего?
Люди часто задаются вопросом, почему я хочу взять уничтожить все эти объекты, а затем снова добавить их. Вы можете потерять работу, если во время обновления базы данных и забудете выполнить скрипт создания вьюхи.Причина проста - чтобы выявить проблему как можно раньше. Если кто-то совершает изменение схемы и это изменение удаляет столбец, используемый в во вью, вы узнаете об этом как можно раньше - скорее всего, прежде чем билд уйдёт в тестирование. Точно так же, если кто-то сохраняте в системе контроля версий вью, но забывает о изменения схемы в которых нуждается это вью, кто-то другой кто собирается обновится на своем рабочем месте через несколько минут уже может спросить, почему первый ломает программное обеспечение.
Вторая причина заключается, чтобы избежать некоторых редких ошибок, которых я видел. Некоторые базы данных имеют тенденцию сохранять план выполнения даже, когда схема меняется под вью. Удалив все и начав сначала можно избежать этой проблемы, которую на самом деле трудно отследить.Конечно, это означает что базе данных потребуется немного времени в downtime для применения обновлений. Я понимаю, что не у всех есть такая роскошь.
Резюме
Благодаря силе системы контроля версий и автоматизации, каждая база данных от разработки до прода имеет синхронизированную схему БД. Если Вам нужно вернуться назад во времени, чтобы увидеть, что было в базе данных была 20 июля 2010 года, или в сборке 1.58 приложения, вы можете сделать это с помощью этой же стратегии.Следующий вопрос: как жить с ветвлением в системе управления контролем версий? Это тема для следующего поста.
comments powered by Disqus