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

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

Данный текст явлется переводом. Оригинал по ссылке

1. Никогда не используйте общий сервер базы данных для разработки.

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

Как и многие другие удобства в разработке программного обеспечения, общая база данных представляет собой озеро природного асфальта ожидающее образования окаменелостей проекта. Разработчики постоянно перезаписывают изменения друг друга. Изменения, которые я делаю на сервере ломаются при работе с кодом на компьютере разработчика. Удаленная разработка становится медленной и трудной.

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

2. Навсегда определите единый, авторитетный источник вашей схемы

В идеале, этим единственным источником будет ваш репозиторий системы контроля версиями (см правило # 3). Рассмотрим следующий разговор разработчиков:

1: Пришло время, чтобы перевести задачу в тестирование. Мы должны скопировать базу данных из машины Джека, или машину Джилл?\

2: Ууууууууууу, я не помню, у кого актуальная база.

1: Мы облажались.

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

Каким образом вы храните вашу базу данных в системе управления версиями зависит от ситуации и предпочтений. Любой приличный ORM должен быть в состоянии создать базу данных заданной отображением определенным в проекте. Вы можете также заскриптовать базу данных в виде набора из одного или нескольких файлов c командами SQL DDL. Я вообще предпочитаю сохранять представления базы данных и программные функции (включая функции, триггеры и хранимые процедуры) в виде отдельных файлов - но об этом в дальнейших публикациях.

Есть много полезных инструментов. Leon Bambrick предоставляет длинный список (которому уже как минимум один год) этих инструментов, которые могут помочь, в то время как Jeff Atwood раскрывает все прелести в Visual Studio для специалистов по базам данных.

3. Всегда версионируйте вашу базу данных

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

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

В то же время, если вы ищете больше правил для работы с базами данных, то Адам Коган и SSW предоставляют отличный список.

Картинка превью взята из slideshare RedgateSoftware