Когда ORM начинает мешать: путь от Doctrine до нативного SQL и библиотеки Thesis

public

Автор: Валентин Удальцов (Happy Inc. / Typhoon) · PHP Russia 2021


Валентин Удальцов в Happy Inc. прошёл полный путь от ORM до нативного SQL — и рассказывает об этом не как об отказе от абстракций ради принципа, а как об архитектурном решении, которое «во всех смыслах выгодно». Отправная точка: ORM, QueryBuilder и прочие абстракции связывают руки при попытке использовать базу данных на полную.

Конкретный вопрос, который задаёт Удальцов: какой смысл выбирать между PostgreSQL, MySQL и Oracle, если ваша библиотека всё равно не умеет в upsert, lateral join, returning, json path и оконные функции? Если абстракция закрывает доступ к возможностям СУБД, которую вы выбрали — это уже не абстракция, это ограничение.

Кому смотреть: PHP-разработчикам, которые чувствуют что ORM начинает ограничивать — но не решаются отказаться от него, потому что «так принято».

Из этого можно взять в работу: найти в своём проекте одно место где вы написали сложный raw SQL внутри ORM-контекста (через DB::raw() или аналог). Если такое место есть — это сигнал, где абстракция уже не помогает.


Путь Happy Inc. как эволюция: Doctrine ORM → DBAL → кастомный QueryBuilder → нативные SQL-запросы. Каждый шаг — ответ на конкретное ограничение предыдущего уровня. Не переход «потому что модно», а решение реальных задач с конкретными SQL-конструкциями.

Результат пути — open-source библиотека Thesis. Её задачи: оформлять SQL-запросы без боли, на лету внедрять параметры любых типов, удобно работать с result set. Это не новый ORM — инструмент для работы с нативным SQL без его «грязных» сторон (конкатенация строк, ручное экранирование).

SQL-возможности, которые открываются без ORM: upsert (INSERT … ON CONFLICT), lateral join, RETURNING (получить данные из INSERT/UPDATE/DELETE), json path, оконные функции (window functions). Всё это стандартный PostgreSQL — и всё это либо невозможно, либо неудобно через типичные ORM.