Зачем нужны миграции?
Если по хорошему, то реальное их практическое применение только в том, что бы создать структуру таблиц, например, при установке какого-то бандла. Допустим, у Вас есть бандл "Новости", что бы Вам "руками" не лезть в базу и не запускать, пусть даже готовый 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).
