[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Флуд от темы про Query Builders
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9
kaww
Цитата (twin @ 22.12.2016 - 14:55)
Зачем парсить sql? И почему andWhere в строку вызова метода билдера вставить проще, чем AND в строку sql?

Допустим, что имеем модульную архитектуру проекта. Есть список пользователей. Есть модуль рейтинга. Когда он включен, то в списке пользователя должен так же выводится рейтинг и не должно быть пользователей с рейтингом < 5
В случае с query bilder'ом это решается просто:
function onUserList($event) {
$query = $event->getTarget();
$query->joinInner('rating', 'rating.user_id=user.id', ['rating_value' => 'value'])->where('rating.value >= ?', 5);
}

В случае с просто запросом:
function onUserList($event) {
$sql = $event->getTarget();
//где $sql = SELECT user.* FROM users INNER JOIN .... LEFT JOIN .... WHERE ..... LIMIT ....
//Тут какие-то магические регулярки, которые все делают хорошо, не ломают запрос и при этом помнят, что кто-то (другой модуль) так же может модифицировать запрос

$event->setTarget($sql);
}
sergeiss
Цитата (McLotos @ 22.12.2016 - 14:01)
я хочу создать инструмент удобный конкретно для меня конкретно в этом проекте =)

Дело твоё личное, конечно smile.gif Но если бы твою энергию, да направить в мирное русло, то было бы намного больше пользы smile.gif

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

user posted image
twin
Цитата (kaww @ 22.12.2016 - 11:16)
//Тут какие-то магические регулярки, которые все делают хорошо, не ломают запрос и при этом помнят, что кто-то (другой модуль) так же может модифицировать запрос

Вообще не понял. Какие магические регулярки? Ты еще больше запутал. sad.gif Сможешь досконально написать оба примера? И результирующие запросы?

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
twin
Всё, понятно. Не врубился сразу. Не трудись. Спасибо. smile.gif

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
Oyeme
Цитата (twin @ 22.12.2016 - 10:55)
Цитата (waldicom @ 22.12.2016 - 09:14)
Или мне просто добвать andWhere(<condition>) или мне парсить строку sql думая, как же мне добавить туда мое условие, чтобы ничего не поломать

А можно поподробнее? Зачем парсить sql? И почему andWhere в строку вызова метода билдера вставить проще, чем AND в строку sql?

Для динамических запросов и для удобства мапигна между моделяи со всеми связами то удобно использовать как ORM doctrine.

Имеет смысл когда проект действительно большой.Например как уже сказали категории в магазине типо ebay.
kaww
Цитата (twin @ 22.12.2016 - 15:26)
Всё, понятно. Не врубился сразу. Не трудись.

Уже потрудился ) . Пусть тогда будет уже.
С задачей вроде все ясно, верно? Есть список пользователей, который выводится запросом:
SELECT users.*, photos.url 
FROM users
LEFT JOIN photos ON photos.user_id=users.id
ORDER BY name DESC
OFFSET 100 LIMIT 50

Есть модуль рейтинга. Когда он включен (например, версия системы для конкретного заказчика), то запрос должен стать таким:
SELECT users.*, photos.url, rating.value AS rating_value
FROM users
LEFT JOIN photos ON photos.user_id=users.id
INNER JOIN rating ON rating.user_id=users.id
WHERE rating.value >= 5
ORDER BY name DESC
OFFSET 100 LIMIT 50

С билдером все просто - см. пост выше. А вот со строкой запроса - нет. Нужно очень исхитриться, чтобы привести первый запрос к виду второго. Просто вернуть новый запрос в методе onUserList мы не можем, т.к. таких onUserList может быть сколько угодно.
waldicom
Цитата (twin @ 22.12.2016 - 11:55)
А можно поподробнее? Зачем парсить sql? И почему andWhere в строку вызова метода билдера вставить проще, чем AND в строку sql?


kaww хорошо все расписал

_____________
Свои мозги еще никто не отменял.
Телепатов нету.
twin
Цитата (Oyeme @ 22.12.2016 - 11:29)
Имеет смысл когда проект действительно большой.Например как уже сказали категории в магазине типо ebay.

Не имеет никакого значения размер проекта. Зависит от изначальной архитектуры. В вашем случае, когда используется архитектура монолитного ООП приложения, это действительно удобно. Но только потому, что нужно как то распутывать этот клубок. Если архитектура реально модульная (сервисная), то никакого смысла в этом нет.

Я в свей свистоперделке тоже сделал (не до конца правда пока) эту хрень, не особо понимая для чего именно. Теперь стало понятно. Полезная тема.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
waldicom
Цитата (twin @ 22.12.2016 - 12:36)
Если архитектура реально модульная (сервисная), то никакого смысла в этом нет.

Я вроде выше описал, что в моем случае конечный продукт позволяет расширять себя модулями (сервисами). И до того момента, пока разработчики не ввели Doctine, было не удобно. Теперь удобно.

_____________
Свои мозги еще никто не отменял.
Телепатов нету.
Invis1ble
Еще можно сократить количество кода в некоторых случаях, простой пример:
https://github.com/Invis1ble/assistant/blob...t.php#L102-L144

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

McLotos
о! Invis1ble сменил аватарку? =)
Вот sergeiss и twin упорно напирают на то что в QB нет смысла, давайте разберем одну простую истину. Вы работаете над проектом пару-тройку лет и в один прекрасный момент понимаете что идеально оптимизированный код все-равно не дает той производительности, которая была когда-то и даже многочисленные оптимизации БД тоже не дают былой скорости. Вы понимаете, что пора бы сменить уставшего дельфина на бодренького и более мощного слоника, но вот беда - все ваши запросы (а их по всему проекту может быть несколько сотен) оптимизированы под работу с конкретным сервером, т.е. с дельфином, а тут вдруг слон, а там синтаксис другой и многие функции дельфина тупо не существуют, но у слона есть их аналоги, и что вам остается? Правильно, бегать по всем моделям и править все запросы под новый синтаксис.
А теперь представьте, что если бы у вас была ORM с хорошим QB, которая работала через PDO и вообще делала много крутых вещей, вам нужно было бы просто воссоздать такую же архитектуру БД с помощью миграций и не меняя ни строчки кода (а только в конфиге заменить слово "дельфин" на "слон") продолжить работу с проектом.

_____________
программирование - инструмент для решения конкретных задач, любая попытка спроектировать что-то универсальное приведет к провалу.©paul85
В любом случае тебе прийдётся пройти путь изобретения велосипеда, который прошли другие, только причиной твоего изобретения будет непонимание принципов работы велосипеда изобретённого другими людьми.©SlavaFr
jQuery это попытка использовать АН-225 для перевозки зубочистки
twin
Цитата (waldicom @ 22.12.2016 - 12:01)
Я вроде выше описал, что в моем случае конечный продукт позволяет расширять себя модулями (сервисами)
Мы просто по разному трактуем понятия "модули" и "сервисы". Да, в твоем случае это удобно, я согласился. Но если модуль самодостаточен, то смысла изменять его функционал в другом модуле нет. Соответственно нет смысла и в билдере. Все зависит от архитектуры.

Цитата (McLotos @ 22.12.2016 - 12:49)
Вот sergeiss и twin упорно напирают на то что в QB нет смысла,

Где это я напирал, да еще и упорно? blink.gif

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
McLotos
Цитата (twin @ 22.12.2016 - 18:57)
Где это я напирал, да еще и упорно?

Ну twin, мы все прекрасно знаем как ты относишься к ООП, следовательно и к таким вещам как ORM и QB тоже.

_____________
программирование - инструмент для решения конкретных задач, любая попытка спроектировать что-то универсальное приведет к провалу.©paul85
В любом случае тебе прийдётся пройти путь изобретения велосипеда, который прошли другие, только причиной твоего изобретения будет непонимание принципов работы велосипеда изобретённого другими людьми.©SlavaFr
jQuery это попытка использовать АН-225 для перевозки зубочистки
McLotos
Что-то флуд получился популярнее чем основная тема с вопросом =)

_____________
программирование - инструмент для решения конкретных задач, любая попытка спроектировать что-то универсальное приведет к провалу.©paul85
В любом случае тебе прийдётся пройти путь изобретения велосипеда, который прошли другие, только причиной твоего изобретения будет непонимание принципов работы велосипеда изобретённого другими людьми.©SlavaFr
jQuery это попытка использовать АН-225 для перевозки зубочистки
twin
Цитата (McLotos @ 22.12.2016 - 13:00)
Ну twin, мы все прекрасно знаем как ты относишься к ООП, следовательно и к таким вещам как ORM и QB тоже.
Разумеется. Я считаю это все бесполезными побрякушками. Особенно несостоятельным доводом "за" я считаю твой последний аргумент.

Однако я не напирал. Тем более упорно. smile.gif Для себя я давно все решил, а вы используйте что хотите. Какой смысл напирать. smile.gif

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2025 Invision Power Services, Inc.