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

Работаю в компании где юзается доктрина (2 версия). Если конечно же доктрина чего то не умеет, то запрос переписывается на plain SQL.

Справедливости ради, я думаю стоит заметить, что ни один из известных мне ORM'ов - не умеет "всего", даже на уровне MySQL'а. А если говорить про более продвинутые БД (в плане функциональных возможностей), например, PostgreSQL - то ORM'ы вообще "мало чего умеют" (в процентном соотношении).

Собственно, я думаю, что это не всё.

Я более чем уверен, что это далеко не всё.

Почему доктрину многие так восхваляют? Пока что я увидел сплошные минусы для себя.

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

P.S. Всё выше написанное, является моим субъективным наблюдением, основанным на моём личном опыте работы со студентами и людьми повышающими свою квалификацию в ракурсе веб-разработок. Уважаемые коллеги, убедительно прошу вас не устраивать срач под этим постом, у меня к сожалению нет времени в достаточном количестве, что бы вести объективную дискуссию, а поддерживать перепалку - желания.

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

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