Зачем нужны миграции?

Question

[magary4]

Если только столбец в таблицу добавить то понятно

а если постоянно таблицу с дынными надо поддерживать в актуальном состоянии? не проще ли держать sql-dump этой таблицы в git/svn ?

Answer 1

[Максим]

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

Comments

[magary4]

а если такой случай - на сервере в продакшене ошибка, чтоб ее увидеть на локале и исправить надо мигрировать структуру постов, папок, категорий и картинок относящихся к ним, как работать ?

[Максим]

magary4: Откатить локальную версию проекта с помощью миграций к версии прода. А вот данные уже не важны. Но если косяк именно завязан на данные, то все зависит от проекта. В простом случае(проект - сайт анекдотов) - можно сделать копию бд и проверять локально. В сложном (проект - банковские данные) - искать причину, "имитировать" эти данные в ручную или с помощью скрипта-генератора данных.

[magary4]

Максим: "Откатить локальную версию проекта с помощью миграций к версии прода. " зачем? структура не менялась, случай когда проблема в данных

[Максим]

magary4: Ну Вы сами так написали "[...]чтоб ее увидеть на локале и исправить надо мигрировать[...]". Если схема такая же, то тогда читать только вторую часть моего комментария :)

Answer 2

[Евгений Вольф]

Зачем нужны миграции?

Если по хорошему, то реальное их практическое применение только в том, что бы создать структуру таблиц, например, при установке какого-то бандла. Допустим, у Вас есть бандл "Новости", что бы Вам "руками" не лезть в базу и не запускать, пусть даже готовый SQL - миграции помогут Вам сделать это в автоматическом или полу-автоматическом режиме.

а если постоянно таблицу с дынными надо поддерживать в актуальном состоянии? не проще ли держать sql-dump этой таблицы в git/svn ?

На счёт SVN'а (по моему, он вымер как класс, даже Hg/Mercurial почти не осталось) не скажу, но мы так и делаем, храним дамп базы в репозитории, в некоторых случаях даже используем хуки Git'а, которые сверяют версии БД и при изменении - переписывают соотв. файл дампа и добавляют его к комиту.

И основная проблема (*исключительно в нашей практике) даже не столько в самих миграциях как таковых, а в ущербности их возможностей, в большинстве случаев. Не редко, миграции покрывают лишь малую часть возможностей БД, обычно это: основные типы полей, внешние ключи и индексы. Таких вещей как: триггеры, хранимые процедуры/функции, виртуальные поля, View'шки, типы данных свойственные конкретной БД или просто "не популярные" типы данных, такие например, как GEOMETRY - очень часто, в миграциях не поддерживаются. Так же, как например, я пока не встречал механизмов миграций, которые бы могли нормально создавать такой элементарный тип, как ENUM в PostgreSQL, не говоря уже про более сложные, составные типы и т.д.

Касательно Symfony, она как и многие другие фреймворки, не поддерживает даже такой типа данных как "ARRAY", вернее то, что в Symfony называется ARRAY - это по факту строка, с сериализованым массивом, а не массив в "чистом виде", который (как тип данных) есть например, в том же PostgreSQL. В виду чего, было бы удивительно ждать чего-то подобного от миграций.

Ни в одном серьёзном/крупно проекте, я пока не видел настолько безумного администратора БД, который бы позволил модифицировать "живую" БД с помощью механизма миграций на уровне фреймворка. Только SQL-код, после предварительного анализа.

На основании всего этого, мы для себя сделали вывод, что миграции отлично подходят для автоматизации создания примитивных болванок в БД, например, тех же "новостей", не более того.

P.S. Я знаю, что для БД существуют специализированные механизмы/программы, для контроля БД, включая данные. Детально пока не разбирался, но подобная возможность ("Контроль версий БД") заявлена, например, в программе SQL Manager for PostgreSQL (для Windows).

Comments

[magary4]

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

[Максим]

В доктрине можно сырой SQL-query сделать:
docs.doctrine-project.org/projects/doctrine-migrat...

Symfony Array - это что? Если относительно doctrine ORM, то там есть специальный тип связи (пункт 5.6)
docs.doctrine-project.org/projects/doctrine-orm/en...

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

[Евгений Вольф]

Максим:

Symfony Array - это что?

Сложно не ошибиться в таком объёме текста, пишущимся "на скорую руку", но, Вы правы, я имел в виду именно "ARRAY" применительно к Doctrine :)

[Евгений Вольф]

magary4: обычно у нас есть "тестовый стенд БД", в котором все данные с оригинально (продакшен/рабочего) сервера, и обязательно строго такая же структура данных. На нем обкатываются новые вариации БД/структуры и в нем же есть обычно срез всех данных с оригинала, но в несколько "укороченном" виде. Например, в оригинальной (рабочей) БД у нас 100тыс. товаров, в тестовой - 10тыс., что бы "не тормозил". Если бы баг возникал исключительно на 100тыс. товаров (записей) - скопировали бы все 100тыс., пофиксили бы баг, подрезали базу до 10тыс.

[Евгений Вольф]

magary4: если нужно изменить структуру БД на оригинале, например что-то добавить/удалить - обычно для этого есть "зеркало" оригинального сервера. У нас работа идёт выглядит примерно так: есть условно 1 сервер или облако, там поднято несколько нод (виртуальных машин), изменения закачиваются на первую свободную, тестируются, если всё ОК - "главный" сервер, который распределяет нагрузку - подключает эту ноду в работу и отключает другую, она становиться тестовой и следующие правки тестируются на ней.

[Dmitry MiksIr]

модифицировать "живую" БД с помощью механизма миграций на уровне фреймворка. Только SQL-код, после предварительного анализа.

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

[Евгений Вольф]

Dmitry MiksIr: такого механизма миграций, я пока не встречал. Всё, что видел я, реализованное на уровне разных фреймворков - это классы, с довольно ущербным функционалом предназначенные для модификации структуры БД, представляющие из себя описание это самой структуры БД, с некоторыми доп. функциями типа "добавить", "удалить" и т.д. И, как считают отдельные особи - отлично заменяющие программы для проектирования/управления БД (в большей степени по тому, что не используют ничего, кроме стандартных полей и базовых возможностей этих самых БД).

Если Вы просветите меня и покажите где можно почитать о механизмах миграций на уровне ФВ, который бы позволял полноценно работать с БД, например проводить анализ различий базы "до" и "после" и генерировать дельту этих различий, или хотя бы просто выполнять полноценные запросы - я буду Вам очень признателен.

[Dmitry MiksIr]

То, о чем вы говорит - это просто сахар. Т.е. возможность написать $this->addColumn. Но кроме этого сахара есть и обычный $this->sql или как там у каждого фреймворка. Вот пример миграции доктрины:

public function up(Schema $schema)
    {
        // this up() migration is auto-generated, please modify it to your needs
        $this->abortIf($this->connection->getDatabasePlatform()->getName() != 'postgresql', 'Migration can only be executed safely on \'postgresql\'.');

        $this->addSql('CREATE SEQUENCE page_id_seq INCREMENT BY 1 MINVALUE 1 START 1');
        $this->addSql('ALTER TABLE page ALTER COLUMN id SET DEFAULT nextval(\'page_id_seq\')');
        $this->addSql('ALTER TABLE page ADD video1 TEXT DEFAULT NULL');
        $this->addSql('ALTER TABLE page ADD body1 TEXT DEFAULT NULL');
        $this->addSql('ALTER TABLE page DROP text');
        $this->addSql('ALTER TABLE page ALTER title DROP NOT NULL');
    }

[Dmitry MiksIr]

Если Вы просветите меня и покажите где можно почитать о механизмах миграций на уровне ФВ, который бы позволял полноценно работать с БД, например проводить анализ различий базы "до" и "после" и генерировать дельту этих различий, или хотя бы просто выполнять полноценные запросы - я буду Вам очень признателен.

Ну если говорить про доктрину, то там мы имеем сущности и соответствующие им таблицы. Меняем сущности и doctine:migration:diff сравнивает текущую схему базы и то, что ожидают сущности - и генерит такую вот миграцию, которая потом проверяется руками, редактируется, дополняется и комитится.

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

[Евгений Вольф]

Dmitry MiksIr: я согласен с тем, что Вы правы на счёт "сахара" и я просто "недоглядел" (не разглядел) подобные возможности у миграций на уровне Doctrine например. Это безусловно добавляет им некоторую долю полезности и возможностей, но всё равно, основное их назначение, которое вижу я - это полу-автоматическое возведение структуры БД для некоего автономного модуля (например, бандла), например, при его установке/внедрении в проект. Но никак не то фанатичное использование под соусом "единственно верный вариант" и "замена всем программам для работы с БД" которое обычно практикуется в некоторых кругах.

[Евгений Вольф]

Dmitry MiksIr:

Ну если говорить про доктрину, то там мы имеем сущности и соответствующие им таблицы. Меняем сущности и doctine:migration:diff сравнивает текущую схему базы и то, что ожидают сущности - и генерит такую вот миграцию, которая потом проверяется руками, редактируется, дополняется и комитится.

Поправьте меня, если я ошибаюсь, но насколько я знаком с сущностями в Symfony/Doctrine - они так же имеют лишь базовые возможности на уровне БД, например, для того же типа данных ARRAY в Postgres'е мне приходилось писать обёртку вручную, т.к. "из коробки" поддержки такого типа в Symfony/Doctrine не было. Исходя из этого, я предполагаю, что команды на подобии doctine:migration:diff позволяют нам работать так же, лишь с базовыми возможностями БД, коих в ряде случаев - критически недостаточно.

[Dmitry MiksIr]

Все так, с базовыми. Хотя у доктрины есть замечательный механизм кастомных типов, которыми можно реализовать многие типы базы https://github.com/opensoft/doctrine-postgres-types

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

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

Ну и есть фреймворки, которые работают по обратному принципу - генерация сущностей на основе схемы (например, Yii). Ну или вообще руками правка и модели и базы. В этом случае мы создаем пустую миграцию и пишем туда все sql инструкции, исполняем миграцию у себя, правим модель.

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

[Евгений Вольф]

Dmitry MiksIr: прежде всего, хочу Вас поблагодарить за конструктивную критику, с которой я полностью согласен. Далее, постараюсь ответить на Ваши вопросы.

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

Очень тяжело описать все процессы в рамках комментария, будучи ещё ограниченным во времени, но основная суть в том, что переходя между разными стадиями (старт, утверждение, разработка, поддержка, и т.д.) некоторые механизмы могут либо отключаться, либо модифицироваться. В зависимости от ситуации, база может дампится не вся, а только та часть данных, которая изменилась например (и структура и данные), если данных мало или не очень много, либо в итоге все используют единую БД и необходимость дампов отпадает (и они отключаются соотв.)

[BoShurik]

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

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

[Евгений Вольф]

BoShurik: командный чат/телефон/скайп/etc, добавляем новое поле, если старое нужно - не трогаем. Всех пнули, что бы обновились, все обновились, удалили старое поле. Пока в принципе, проблем особых с этим не было, особенно если поля из базы не удалять раньше времени. Это гораздо удобнее, чем получать "пустую" базу после миграций, т.к. новое поле может быть не только создано, но и заполнено сразу.

[BoShurik]

Евгений Вольф: я имею в виду ситуацию, когда я пилю фичу, в которой надо как-то изменить БД. Т.е. разработка тут заключается в двух шагах, грубо говоря: изменить БД и, собственно, реализовать логику с использованием этих изменений. Т.о. может получится так, что база изменена, а логика фичи еще не реализована (т.е. самого кода в VCS еще нет).

> Это гораздо удобнее, чем получать "пустую" базу после миграций, т.к. новое поле может быть не только создано, но и заполнено сразу.
А что мешает как-то инициализировать это поле в миграции?

[Евгений Вольф]

BoShurik:

Т.о. может получится так, что база изменена, а логика фичи еще не реализована (т.е. самого кода в VCS еще нет).

Может получиться так: в базу добавлено новое поле, но не удалено старое. Тогда и старый код работает и новый будет выгружен сразу, как будет готов. Таких ситуаций, что бы поле "title" внезапно стало INT, когда было CHAR и при этом сохранило своё имя, т.е. той ситуации, при невозможно добавить новое поле и сохранить при этом старое (временно) - я не могу припомнить. А само по себе наличие нового поля в базе, практически всего - никак не ломает логику работы приложения. Но даже в этом случае, можно склонировать рабочую ноду (у нас это делается в пару кликов) и перебить IP/домен подключения к БД туда, временно, а потом сразу выгрузить и данные и код. Но это случай 1 на миллион наверное. Я пока не могу так вот сходу представить ситуацию, в которой бы добавление нового поля в БД - внезапно сломало код (я имею в виду адекватный код).

[BoShurik]

Евгений Вольф: Ну, к примеру. Раньше поле хранило путь до картинке, а теперь должно хранить json с метаданными (размер, дата загрузки и прочая фигня). Если так нужно согласование с администратором БД. то для этого есть pull-реквесты.
Сомнительный у вас воркфлоу. С точки зрения бюрократии - возможно и хорошо, а с точки зрения разработки - ад :)

[Евгений Вольф]

Сомнительный у вас воркфлоу. С точки зрения бюрократии - возможно и хорошо, а с точки зрения разработки - ад :)

Я согласен с Вами, с Вашей точки зрения, но это немного не так на самом деле. Просто мне довольно трудно расписать бизнес-процесс над которым мы работали года 4, в рамках комментария... Есть конечно "узкие места" в этой системе, но мы попробовали разные варианты, и с миграциями и без, и так и эдак... и миграции - в конкретно нашем случае, отлично вписались в роли эдакого, автоматизированного куска кода, для сущностей уровня "бандл", что-то вроде "install script", знаете, как SQL-запрос при создании/установке модулей для Joomla'ы... В качестве продакшена, если даже отбросить вариант "случайно убилась база" (миграции сами по себе в этом безусловно виноваты не были), то проблема "залить всем данные" остаётся всё такой же актуальной, при любом раскладе, в котором база не централизовано, с миграциями или без них... Централизованная БД, хоть и имеет ряд своих недостатков - имеет так же, массу своих преимуществ, это как язык высокого уровня, он "хуже" "чистого Си", в т.ч. по производительности кода и т.д., но имеет ряд преимуществ, например в производительности разработчиков.

Answer 3

[Sanes]

Миграции вроде с данными не работают. Только с самой архитектурой.

Comments

[Ivan Stroykin]

Именно. Для данных есть дампы

[magary4]

Иван Стройкин: что вы имеете ввиду по дампами? команда mysqldump ?
или какие-то другие тулы?

[Ivan Stroykin]

magary4: нет, я имею в виду что автор этого ответа прав. И нет, команды это команды, а дамп - это файл, и не имеет значения как вы его получите (какой командой или еще чем). Чтобы не работать "ручками" каждому разработчику проекта. Чтобы каждый не лазил в БД и не менял колонку с "name" на "first_name" существуют миграции. А для актуальности данных у каждого разработчика обычно заводят локатор (место хранения дампов) из которого любой разработчик может всегда забрать свежий дамп и развернуть у себя

Answer 4

[Константин Б.]

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

Comments

[magary4]

в чем отличие если я просто добавлю в гит файл с содержанием ALTER TABLE user RENAME COLUMN ....

[Константин Б.]

Из документации Laravel - первого результата в гугл
Миграции - это что-то вроде системы контроля версий для вашей базы данных. Они позволяют команде программистов изменять структуру БД, в то же время оставаясь в курсе изменений других участников. Миграции обычно идут рука об руку с конструктором таблиц для БОЛЕЕ ПРОСТО ОБРАЩЕНИЯ с архитектурой вашего приложения.