Добрый день.
Кто из опытных скажет основные преимущества Doctrine по отношению скажем к PDO? Правильно ли я понимаю, что это практически полное абстрагирование от синтаксиса sql? И в чем плюс. Что мы может много разных баз данных использовать в больших проектах и не городить везде разные подключения и запросы на своем синтаксисе?

SoMeOnE, Doctrine ORM и PDO - это разные и не сравнимые вещи. Doctrine, так же как pdo, предоставляет универсальный интерфейс доступа к БД, но если DQL (doctrine query language) - это слой абстракции над языком запросов, то в pdo используются нативные sql различных БД. И доктрину стоит рассматривать именно как orm (чем она, собственно, и является), а не только как драйвер доступа к БД.

З.Ы. К плюсам доктрины относят то, что dql полностью (в отличии от pdo ) позволяет абстрагироваться от используемой БД и без изменения кода программы менять хранилище. Но по факту (на сегодняшний день) это не совсем так, и на самом деле doctrine хорошо работает только сmysql.

SoMeOnE для меня например плюсом является то что используя ее, не надо заботиться о миграциях, так как на основе метаданных она востоновит(создаст, обновит, удалит) все таблицы в бд. Также удобно кода у тебя есть готовая абстракция над связями между сущностями. Если вы любите писать код руками, то плюсов для себя вы не найдете.


_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

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

chee, ну да пока не вижу. Пока еще плаваю, как, что и зачем)
я разве что подумал цепляй любые базы sql, nosql и работай. Я знаю, что в том проекте котором работаю еще в некторых местах sql light используется. Подумал он все поддерживает. Ну хотя бы многое

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

Кто-нибудь может привести убедительный пример, когда смена СуБД обусловлена чем-то иным?

Мн елично в ORM нравится, что не нужно самому париться, писать какие-то joins's. Там просто при проектировании создаешь правильные связи, все остальное ORM делает сама.

_____________
Свои мозги еще никто не отменял.
Телепатов нету.

waldicom, круто, вот только к аннотациям нужно привыкнуть.

Начнём с того, что в доктрине есть DBAL и ORM.

Главня задача всех без исключения ORM - представить записи из таблицы БД в виде объектов в коде программы. Все остальные преимущества - избавление от рутины, контроль ошибок, те же миграци - всего лишь плюшки. Но очень удобные и нужные плюшки.

Касательно DBAL. Вот его уже можно сравнить с PDO. По сути, примерно тоже самое, но с расширенным функционалом: логирование, типы и пр.

Безболезненная смена хранилища - это вообще за уши притянутая фича. Тем не менее, почему именно она приходит первой на ум почти всем, кто поднимает разговор об ORM. Я видел только один проект, где планировали сменить mysql на postgresql. И то, в том состоянии проекта, это была далеко не приоритетная задача.
Если проект достиг той стадии развития, что приходится менять хранилище. Безболезненно эта смена точно не пройдёт.