Миграции (migrations) и сиды (seeds).

База данных, вне зависимости от того, какая она, будь то Postgresql, MySQL или даже MSSQL всегда является достаточно важным элементом любого проекта. От того, насколько правильно и гибко будет настроена архитектура этой базы данных зависит очень многое - начиная от возможности реализации нововведений и заканчивая временем, затрачиваемым на исправление в ней ошибок. Конечно, это правило не касается баз данных вида NoSQL, потому что как таковой, настраиваемой архитектуры они не имеют, а всё представлено просто набором коллекций (массивов документов).

Так вот, наверняка многие ввиду своей неопытности (как делал и я) создают самые обыкновенные SQL-скрипты на создание/удаление таблиц базы данных, внесение/удаление начальных данных. Чем это плохо?

1. На каждое изменение в базе данных (допустим, смена названия столбца) придется создавать 2 файла - один на изменение, второй на его откат в случае возникновения проблем.
2. Могут возникать проблемы с версионностью проекта. Это означает, что допустим, Вы будете создавать на каждое изменение в БД отдельный скрипт, но спустя долгое время вам потребовалось откатить его до определенной версии. Выполнить эту операцию будет достаточно сложно ввиду того, что Вы просто не вспомните, в какой последовательности запускали эти скрипты.

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

Миграции (migrations)

Итак, миграции - это определенный пакет изменений базы данных. Их можно найти в таких фреймворке как Laravel (для PHP) и модуле KnexJS (для NodeJS). Дело в том, что эти элементы позволят Вам использовать миграции, написанные на тех же языках, для которых они разработаны. То есть для Laravel миграции будут написаны на PHP, для NodeJS - JavaScript. Это достаточно удобно, потому что у Вас нет необходимости вообще знать SQL. Они просто конвертируют ту миграцию, которые Вы написали в аналог на SQL и отправят указанной базе данных.

В этой статье рассмотрен пример миграции на KnexJS. Гайд по настройке своих фрэймворков (или модулей) можно найти на официальных сайтах. На рисунке 1 представлен список всех миграций проекта, над которым я работаю в данный момент. 

Рисунок 1. Список всех миграций

Модуль KnexJS сам создает файл миграции и создает уникальное название во избежание коллизий. Создать миграцию можно командой:

knex migrate:make [name]

Контент, пожалуй, самой большой миграции (create_donations) представлен на рисунке 2.

Рисунок 2. Контент миграции create_donations

Как видно из кода, всё достаточно понятно. Конечно, возможно, код SQL чуть более компактен, но тем не менее, если Вам важно избежание дальнейших возможных проблем, то эта для Вас проблемой не станет. 

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

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

knex migrate:latest

Для отката последней миграцаии:

knex migrate:rollback

Сиды (seeds)

Сиды, то есть "семена" Вашего проекта. Это начальные данные, то есть, к примеру, данные в справочниках (или словарях, кто как привык). На рисунке 3 представлены сиды двух таблиц моего проекта опять же, на KnexJS.

Рисунок 3. Сиды таблиц user_types и widget_types

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

На этом вроде всё. Подробнее можно почитать на хабре, где более опытные программисты раскладывают всё по пунктикам: https://habrahabr.ru/post/121265/. 

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