Чем оправдано использование QueryBuilder и ActiveRecord в одном проекте?

Question

[Alexander]

Чем оправдано использование QueryBuilder и ActiveRecord в одном проекте?
Очень интересует, как оправдать использование этих двух подходов работы с БД в одном проекте... И разумно ли использовать один QueriBuilder в таком случае и отказаться от ActiveRecords, в частности при использовании запросов с JOIN, UNION

Answer 1

[Александр Аксентьев]

AR как правило использует свой QueryBuilder.
И в сумме называется это ORM
А так же QueryBuilder можно вызывать "напрямую" т.к. он публичный.

Так что это не взаимозаменяемые вещи вообще.
Другой вопрос если используется две разные не связанные библиотеки, это уже что-то страшное. Я такого не встречал.
Ну и что-то подсказывает что так делать не надо.

Comments

[Alexander]

> И в сумме называется это ORM
Наконец-то я догнал что из себя оно представляет. Я потерялся в лесу среди AR, QUERYBUILDER, DAO, DOCTRINE и в частности ORM... Вы открыли мне глаза. Спасибо

Answer 2

[Алексей Николаев]

ActiveRecord в большинстве случаев подходит только для простых запросов. В случае чего-то более-менее заковыристого приходится лезть в модель и городить огород из правил разной степени кривости (если фреймворк поддерживает), или еще хуже - писать все вручную. Два варианта плохи по определению. Поэтому ActiveRecord для простых операций, а QueryBuilder (или какой-нибудь нативный и удобный объект для работы с БД) с блэкджеком и шл PDO и плейсхолдерами - для всего остального.

Отказываться не стоит, просто нужно использовать молоток для забивания гвоздей, а лопату - для копания. ActiveRecord адски удобен, при простых выборках или рядовых insert \ update он смотрится просто великолепно и делает код более простым и наглядным. В проектах ИМ 80% операций с базой идет через AR, и это очень облегчает жизнь.

Comments

[Alexander]

Мне интересна следующая ситуация:

Есть код на AR вида findBySql($sql). $sql соответственно имеет в себе саму строку запроса(допустим с UNION). Так же допустим что такие запросы - экзотика и используются редко, но в разных кусках проекта(придется искать). При переезде например с Mysql на Oracle или MSSQL, синтаксис запроса придется менять, однако не так просто найти. Сможет ли Квери билдер недопустить этого. Как я понимаю, в можно просто в его методах немного подправить синтаксис и не придется мучаться, в поисках нужных кусков кода по всему проекту?

[Alexander]

Оправдано ли использование Кверибилдера в случаях, когда он используется крайне редко?

[Алексей Николаев]

Alexander: да, сможет, но это зависит от того, на чем (какой фреймворк) вы пишете. В идеале вы просто должны сказать ядру, какой драйвер для БД использовать, и не задумываться насчет деталей реализации.

А какая у вас альтернатива? Если вы в этих случаях пишете в AR метод, который напрямую к AR не относится (например, findBySql), и как следствие, все равно используете подготовку и сборку запросов (иначе все еще хуже), то какой смысл писать и форматировать все вручную?

[Алексей Николаев]

Alexander: к тому же, ниже вам написали, что там все взаимосвязано

Answer 3

[trevoga_su]

ПРЕЖДЕ ЧЕМ СПРАШИВАТЬ ТАКОЕ, НАДО понимать, что такое QueryBuilder и что такое ActiveRecord

QueryBuilder - это конструктор SQL запроса
ActiveRecord - это ORM

эти две технологии по факту, теоретически НИКАК не связаны между собой, но ORM скорее всего использует QB

И разумно ли использовать один QueriBuilder в таком случае и отказаться от ActiveRecords, в частности при использовании запросов с JOIN, UNION

Да. Это нормальная практика. Не надо с помощью ORM пытаться делать большие запросы. ORM - для тривиальных вещей.

Answer 4

[Fortop]

Зависит от размера проекта.

Для прототипирования AR лучше.

Для крупной разработки нужен будет билдер запросов.

Соответственно можно использовать первое и переписывать на второе по мере роста