Цитата (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();
$event->setTarget($sql);
}
sergeiss
22.12.2016 - 15:20
Цитата (McLotos @ 22.12.2016 - 14:01) |
я хочу создать инструмент удобный конкретно для меня конкретно в этом проекте =)
|
Дело твоё личное, конечно
Но если бы твою энергию, да направить в мирное русло, то было бы намного больше пользы
_____________
*
Хэлп по PHP*
Описалово по JavaScript *
Хэлп и СУБД для PostgreSQL*
Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги. *
"накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
Цитата (kaww @ 22.12.2016 - 11:16) |
//Тут какие-то магические регулярки, которые все делают хорошо, не ломают запрос и при этом помнят, что кто-то (другой модуль) так же может модифицировать запрос |
Вообще не понял. Какие магические регулярки? Ты еще больше запутал.
Сможешь досконально написать оба примера? И результирующие запросы?
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
Всё, понятно. Не врубился сразу. Не трудись. Спасибо.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
Цитата (twin @ 22.12.2016 - 10:55) |
Цитата (waldicom @ 22.12.2016 - 09:14) | Или мне просто добвать andWhere(<condition>) или мне парсить строку sql думая, как же мне добавить туда мое условие, чтобы ничего не поломать |
А можно поподробнее? Зачем парсить sql? И почему andWhere в строку вызова метода билдера вставить проще, чем AND в строку sql?
|
Для динамических запросов и для удобства мапигна между моделяи со всеми связами то удобно использовать как ORM doctrine.
Имеет смысл когда проект действительно большой.Например как уже сказали категории в магазине типо ebay.
Цитата (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
22.12.2016 - 15:34
Цитата (twin @ 22.12.2016 - 11:55) |
А можно поподробнее? Зачем парсить sql? И почему andWhere в строку вызова метода билдера вставить проще, чем AND в строку sql?
|
kaww хорошо все расписал
_____________
Свои мозги еще никто не отменял.
Телепатов нету.
Цитата (Oyeme @ 22.12.2016 - 11:29) |
Имеет смысл когда проект действительно большой.Например как уже сказали категории в магазине типо ebay. |
Не имеет никакого значения размер проекта. Зависит от изначальной архитектуры. В вашем случае, когда используется архитектура монолитного ООП приложения, это действительно удобно. Но только потому, что нужно как то распутывать этот клубок. Если архитектура реально модульная (сервисная), то никакого смысла в этом нет.
Я в свей свистоперделке тоже сделал (не до конца правда пока)
эту хрень, не особо понимая для чего именно. Теперь стало понятно. Полезная тема.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
waldicom
22.12.2016 - 16:01
Цитата (twin @ 22.12.2016 - 12:36) |
Если архитектура реально модульная (сервисная), то никакого смысла в этом нет. |
Я вроде выше описал, что в моем случае конечный продукт позволяет расширять себя модулями (сервисами). И до того момента, пока разработчики не ввели Doctine, было не удобно. Теперь удобно.
_____________
Свои мозги еще никто не отменял.
Телепатов нету.
Invis1ble
22.12.2016 - 16:20
McLotos
22.12.2016 - 16:49
о! Invis1ble сменил аватарку? =)
Вот sergeiss и twin упорно напирают на то что в QB нет смысла, давайте разберем одну простую истину. Вы работаете над проектом пару-тройку лет и в один прекрасный момент понимаете что идеально оптимизированный код все-равно не дает той производительности, которая была когда-то и даже многочисленные оптимизации БД тоже не дают былой скорости. Вы понимаете, что пора бы сменить уставшего дельфина на бодренького и более мощного слоника, но вот беда - все ваши запросы (а их по всему проекту может быть несколько сотен) оптимизированы под работу с конкретным сервером, т.е. с дельфином, а тут вдруг слон, а там синтаксис другой и многие функции дельфина тупо не существуют, но у слона есть их аналоги, и что вам остается? Правильно, бегать по всем моделям и править все запросы под новый синтаксис.
А теперь представьте, что если бы у вас была ORM с хорошим QB, которая работала через PDO и вообще делала много крутых вещей, вам нужно было бы просто воссоздать такую же архитектуру БД с помощью миграций и не меняя ни строчки кода (а только в конфиге заменить слово "дельфин" на "слон") продолжить работу с проектом.
_____________
программирование - инструмент для решения конкретных задач, любая попытка спроектировать что-то универсальное приведет к провалу.©paul85
В любом случае тебе прийдётся пройти путь изобретения велосипеда, который прошли другие, только причиной твоего изобретения будет непонимание принципов работы велосипеда изобретённого другими людьми.©SlavaFr
jQuery это попытка использовать АН-225 для перевозки зубочистки
Цитата (waldicom @ 22.12.2016 - 12:01) |
Я вроде выше описал, что в моем случае конечный продукт позволяет расширять себя модулями (сервисами) |
Мы просто по разному трактуем понятия "модули" и "сервисы". Да, в твоем случае это удобно, я согласился. Но если модуль самодостаточен, то смысла изменять его функционал в другом модуле нет. Соответственно нет смысла и в билдере. Все зависит от архитектуры.
Цитата (McLotos @ 22.12.2016 - 12:49) |
Вот sergeiss и twin упорно напирают на то что в QB нет смысла, |
Где это я напирал, да еще и упорно?
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
McLotos
22.12.2016 - 17:00
Цитата (twin @ 22.12.2016 - 18:57) |
Где это я напирал, да еще и упорно? |
Ну twin, мы все прекрасно знаем как ты относишься к ООП, следовательно и к таким вещам как ORM и QB тоже.
_____________
программирование - инструмент для решения конкретных задач, любая попытка спроектировать что-то универсальное приведет к провалу.©paul85
В любом случае тебе прийдётся пройти путь изобретения велосипеда, который прошли другие, только причиной твоего изобретения будет непонимание принципов работы велосипеда изобретённого другими людьми.©SlavaFr
jQuery это попытка использовать АН-225 для перевозки зубочистки
McLotos
22.12.2016 - 17:00
Что-то флуд получился популярнее чем основная тема с вопросом =)
_____________
программирование - инструмент для решения конкретных задач, любая попытка спроектировать что-то универсальное приведет к провалу.©paul85
В любом случае тебе прийдётся пройти путь изобретения велосипеда, который прошли другие, только причиной твоего изобретения будет непонимание принципов работы велосипеда изобретённого другими людьми.©SlavaFr
jQuery это попытка использовать АН-225 для перевозки зубочистки
Цитата (McLotos @ 22.12.2016 - 13:00) |
Ну twin, мы все прекрасно знаем как ты относишься к ООП, следовательно и к таким вещам как ORM и QB тоже. |
Разумеется. Я считаю это все бесполезными побрякушками. Особенно несостоятельным доводом "за" я считаю твой
последний аргумент.
Однако я не напирал. Тем более упорно.
Для себя я давно все решил, а вы используйте что хотите. Какой смысл напирать.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
Быстрый ответ:
Powered by dgreen
Здесь расположена полная версия этой страницы.