DBAL

Так можно же там свои сложные запросы, если по другому не получается, пихать в виде строки?

http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/d...

Правда, это не очень хорошо, слегка противоречит самой сути DBAL-а. Но если очень надо... Только как нибудь помечай такое, что оно только для MySQL'а. Например, для сборки нужных данных используешь интерфейс специального адаптера, а под этот интерфейс делаешь только МySQL'ный адаптер, который во время сборки обслуживаемого объекта и указываешь вместо слота интерфейса. А в этом адаптере рисуешь свои сложные, крутые, узко-заточенные запросы. :) А так, DBAL (Doctrine database abstraction & access layer) нужен чиста для переносимости, как органическая часть довольно хорошей вещи - ORM (Object-relational mapping). Они оба нужны для принципа «разделяй и властвуй». Когда работаешь с самими данными, чтоб было наплевать, откуда они взялись, и куда ляжет, и какой тип базы данных это обслужит. Ну это всё в идеале, конечно. :)

М-да, почитал твои другие темы. Да ты-ж совсем новичок... Тогда смотри сразу на сторону ORM, как своего освободителя от сложных запросов. Если после ознакомления появится искушение использовать сложный запрос для чего-то другого, как хорошо оптимизированного сбора статистики по куче таблиц «прямо здесь и сейчас, чтоб было!», сразу спрашивай себя, что ты делаешь не так. :)

К стати, вынос логики в приложение - это не единственный способ. Можно наоборот, всю нужную логику запихать в процедуры, view'ы а в приложении только их и вызывать, не утруждая себя какой там Doctrine. В этом тоже есть свои плюсы и минусы.

а смысл dbal без orm?

Я пришел к компромису и выбрал nativeQuery из той же доктрины, плюс в том, что и ORM не теряется полностью и гибкость есть, и бинды есть. Вообще билдеры sql такая гадость..! Для чего нужно поддерживать переносимость?

Тут вот в чём дело - ты или можешь посвятить работу с базой данных определённому движку базы данных, или наоборот, стараться быть независимым от него. Это как рыба и мясо - хорошие, но очень разные вещи, а мешанина между ними порождает хаос. Так вот, переносимость обеспечивает второе. А при первом, да, она идёт на фиг, ибо не нужна. Оба выбора имеет свои огромные плюсы и маленькие минусы, пригодны для разных целей. В первом - ты используешь всю мощь и мега фичи движка базы данных (Oracle там или MSSQL), но тогда база данных у тебя что-то подобное мини проекту, со своей логикой, форнтендом, бякендом и т.д.. Во втором у тебя логика в одном месте, а база данных - так, придаток к проекту, чтоб где-то держать данные. Большинство мелких проектов выбирает второй путь, так как им выигрыш с фичей базы данных большой роли не играет. Им лишь бы где то свои простенькие данные оставить/забрать. С другой стороны, не представляю, зачем платить, например, за MSSQL и не использовать всей его крутости. :)

ORM обычно выбирают для средних проектов где нужно по быстрому что-то реализовать.
В мелких они не уперлись, а в крупных это оверхед, где в целях оптимизации приходится часами ползать в отладчике чтобы это кусок сгенерировал адекватный SQL.
Я бы предпочел вообще их не касаться.

а смысл dbal без orm?

Смысл в том, что QueryBuilder может билдить запросы к разным бд по одному и тому же описанию.

какая то каша получается

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

подзапросы вообще непонятно как составлять

Отдельно, потом вставляешь в свой запрос через '(' . $subQuery->getSQL() . ')' Если часто надо, можешь хэлпер соорудить, чтобы скобки прикручивать.

нет например банального RAND(), enum

Не совсем понял, что нужно? dbal создаёт только структуру запроса, а данные оно берёт как есть - $queryBuilder->select('rand()'), не? Но вообще, лучше наследоваться от ExpressionBuilder и добавить свои выражения, чтобы не хардкодить строками.

В мелких они не уперлись

Автор использует Symfony framework, так что, если в нём Doctrine идёт из коробки, почему не использовать? :) А для ну очень маленьких проектов «раз сделал, запустил и оставил» до 7 таблиц я тоже жирный чужой ORM не использую: сразу делаю свои простенькие объекты - эксперты данных, которые посылает нужные запросы и параметры в самодельный простенький адаптер, который уже выполняет системные функции для работы с самой базой данных. Очень просто, легко специфицировать, тестировать, а при возможном расширении - перенести внутренности на любой ORM. :)

Он наверняка не пользуется и половиной всего что есть в SF. И если это не рабочий проект, то проще было бы слезть на микрофреймворк на её компонентах.
То же самое бы вышло и гораздо проще.

Он наверняка не пользуется и половиной всего что есть в SF

Да я и не сомневаюсь. :) Но, раз ему интересно, почему не рассказать.