Nested Sets и Data Mapper

[fixxxer]

еще и qb от orm не отличаем

я всё))

 

[WMix]

еще и qb от orm не отличаем

и qb в ORM (Doctrine Query Language в других случаях) от qb для базы тоже (особенно контекст беседы).. и я все

 

[Вурдалак]

почему одна? нужна напиши еще одну

Зачем еще одну??? А как же потом переименовать поле и разбивать на 2? В двух моделях???

 

[WMix]

А как же потом переименовать поле

вероятно тут ты прав, но это меньшее из зол? нет? подскажи способ сделать лучше
знал бы прикуп

 

[MiksIr]

вероятно ты qb не видел еще и рассуждаешь рамками https://spiral.dev/docs/database-query-builders

хочешь на sql

return $this->select()->with('subtree')->where('subtree.id', $id);

этой цепочки из qb https://cycle-orm.dev/docs/query-builder-basic посмотреть

SELECT `node`.`id` AS `c0`, `node`.`pid` AS `c1`, `node`.`name` AS `c2`
FROM `node` AS `node`
INNER JOIN `node` AS `node_subtree`
    ON `node_subtree`.`tree_id` = `node`.`tree_id` AND (`node_subtree`.`lft` > `node`.`lft` AND `node_subtree`.`rgt` < `node`.`rgt`  )
WHERE `node_subtree`.`id` = ?

Ну, во-первых, тут лукавство, ибо этот qb связан с ORM, а о нем речи не шло, ну и тут простота твоей записи скрывает за собой еще десятки строчек описания связей в моделях (https://phpclub.ru/talk/threads/nested-sets-и-data-mapper.86640/#post-772696 - вроде вот такой порнографии). И, во-вторых, это все еще слишком простой запрос для того, что бы ощутить разницу. Чем сложнее запрос, тем виднее будет разница и тем печальнее попытка выразить нормальный структурированный язык sql в какой-то пхп псевдокод ради непонятно чего.

 

[WMix]

Ну, во-первых, тут лукавство, ибо этот qb связан с ORM

разве это важно?

вроде вот такой порнографии

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

 

[MiksIr]

разве это важно?

Да, конечно. Без orm твой запрос выраженный в виде qb выглядел бы иначе - сильно сложнее.

 

[WMix]

Без orm твой запрос выраженный в виде qb выглядел бы иначе

я не об этом, я о том что не важно как устроен qb, важно какой профит.

 

[grigori]

дорогие зрители, вам был представлен наглядный пример к поговорке "заставь дурака богу молится - он лоб разобьет"

 

[grigori]

QB нужен не для того, чтобы сделать написание и чтение запросов проще, а для повторного использования SQL со сложными структурами базы.
Например, это нужно в ecommerce с EAV-структурой, в CRM. Там, где есть много десятков похожих страниц, на которых запросы включают в себя join 5ти одних и тех же таблиц с фильтром по флагам-статусам. Удобно выделить несколько типичных блоков, и добавлять условия в запрос модульно по контексту.

Писать SQL сейчас намного проще в plain text благодаря автокомплиту в IDE, которая читает структуру базы. Но когда у нас запросы на 2 экрана, копипастить большие одинаковые блоки каждый раз хреново.

А по сути вопроса в топике - аффтор, не тереби яйца. Паттерны дизайна - это обобщение практики в некотором наборе случаев, а не вопросы для "Что? Где? Когда?". ORM - паттерн автоматизации для стандартных запросов. Твоя задача нестандартная - пиши ее решение простым кодом без ORM.

 

[WMix]

использования SQL со сложными структурами
EAV-структурой
запросы включают в себя join 5ти одних и тех же таблиц с фильтром по флагам-статусам
запросы на 2 экрана

Писать SQL сейчас намного проще в plain tex

умно

 

[fixxxer]

ORM - паттерн автоматизации для стандартных запросов.

Не совсем. ORM - это паттерн для маппинга внутреннего состояния объектов на таблицы и поля в РСУБД и обратно. Если "стандартными запросами" считать запросы, которые ORM генерирует для персистенции, то, ну да.

 

[MiksIr]

Удобно выделить несколько типичных блоков, и добавлять условия в запрос модульно по контексту.

Именно. Написать базовый запрос на sql. И добавлять к нему блоки через qb. Или убирать что-то не нужное из него.

 

[AmdY]

QB нужен не для того, чтобы сделать написание и чтение запросов проще, а для повторного использования SQL со сложными структурами базы.

QB - это средство для пошагового построения сложных объектов, чьё создание может быть разнесено по разным местам. Проблему повторного использования он никак не решает.
Повторное использование решается ждругими средствами, например паттерном фильтр - создаёшь Criteria в котором с помощью билдера строишь свой запрос. https://www.doctrine-project.org/projects/doctrine-orm/en/2.7/reference/query-builder.html#adding-a-criteria-to-a-query

 

[grigori]

@AmdY терминологию можно обсуждать бесконечно. Из пошагового построения запроса следует возможность вынести часть шагов и сделать повторное использование. Criteria - обертка для QB. А разбор базового sql в ast обсуждался выше.