Дневник web-разработчика 02. База данных и алгоритм миграции

Описывая стек технологий в прошлой статье, я совсем забыл рассказать о том, какую базу данных выбрал для своего веб-приложения. И выбрал я ничто иное как Postgresql. Эта база данных знакома наверное каждому веб-разработчику. Но возможно вам интересно, почему выбор был сделан не в пользу популярного MySQL?

Дело в том что я выбрал Postgresql по двум причинам:

1. Эта система управления базой данных бесплатная
2. Я с ней хорошо знаком

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

На начальном этапе в базе данных планируется хранить следующую информацию:

• пользователей,
• ежедневные задачи пользователей,
• состояние задач пользователей на определенную дату

Стоит отметить, что в этом проекте (GTD-tan) я впервые решил использовать систему миграции данных Flyway. Что это вообще такое?

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

Существует несколько способов обезопасить себя. Стоит пробежаться по некоторым.

Как поддерживать базу данных в актуальном состоянии

Во-первых, таблицы в базе данных можно сгенерировать прямо из кода. ORM-фреймворк для Java под названием Hibernate вполне с этим справляется. Разработчик должен просто создать классы и указать какие таблицы в базе данных должны создаваться на основе этих классов. Тут мне стоит остановиться, потому что Object-Relational Mapping (ORM) - это тема для отдельной статьи.

Во-вторых, можно настроить периодический бэкап (также известный как “резервное копирование”) схемы таблиц в БД. Полученный бэкап можно сохранять в Системе Контроля Версий, или где-нибудь еще.

И наконец, третий способ - использование механизма миграции. В этом случае мы сохраняем последовательные изменения схемы таблиц БД как серию патчей, которые потом накатываются на базу сразу после того как приложение стартует. По сути вместе с кодом мы сохраняем еще и актуальное состояние базы. Этот механизм здорово облегчает миграцию данных. У нас появляется возможность автоматически исполнять код на SQL для базы, в том числе и трансформировать данные, что очень удобно при администрировании боевой базы.

Существует не так уж и много решений, реализующих механизм миграции. Я знаком только с FlyWay и LiquiBase. LiquiBase считает более мощным инструментом.

Так, думаю на этом достаточно. В следующей посте, думаю, стоит рассказать про сборку и деплоймент приложения.

Предыдущий пост
Первый пост в серии
Группа в ВК, посвященная разработке этого веб-приложения