Laravel по-русски

Русское сообщество разработки на PHP-фреймворке Laravel.

Ты не вошёл. Вход тут.

#1 14.11.2016 22:29:52

Select..in(). Сырые запросы против ORM

Добрый день.
При формирование сырого запроса, возникает ошибка.

Запрос в коде выглядет так:

// SELECT * FROM categories WHERE category_id IN  (480,479)
DB::select('SELECT * FROM categories WHERE category_id IN  (?)', [implode(',', $сategories)]);


Вылетает ошибка

Invalid text representation
: 7 ERROR:  invalid input syntax for integer: "480,479" (SQL: SELECT * FROM categories
WHERE category_id IN  (480,479))</span>

Полагаю, ошибка возникает, когда laravel хочет подставить вместо ? строку "480,479", которая по себе не является int.

Как передать массив id для селекта в таком случае, в чем подковырка?

Не в сети

#2 14.11.2016 23:04:03

Re: Select..in(). Сырые запросы против ORM

DB::table('table_name')->whereIn('category_id', [1,2,3])->get();
у меня любой сырой запрос === увольнение.

Не в сети

#3 14.11.2016 23:06:25

Re: Select..in(). Сырые запросы против ORM

Во-первых, не надо использовать сырые запросы (DB::…), надо использовать Eloquent, т.к. он намного удобнее.

Во-вторых, действительно, ошибка из-за того, что «?» это всегда один параметр, числа через запятую трактуются как одно «не-число». Если уж использовать DB::select (хотя зачем, для такого-то простого запроса?), то что-то вроде:

PHP
if ($categories) {
  
$ph '?'.str_repeat(', ?'count($categories) - 1);
  
DB::select('SELECT * FROM categories WHERE category_id IN  ('.$ph.')'$сategories);
}

Не в сети

#4 14.11.2016 23:55:03

Re: Select..in(). Сырые запросы против ORM

Proger_XP пишет:

}%Во-первых, не надо использовать сырые запросы (DB::...), надо использовать Eloquent, т.к. он намного удобнее.

Во-вторых, действительно, ошибка из-за того, что "?" это всегда один параметр, числа через запятую трактуются как одно "не-число". Если уж использовать DB::select (хотя зачем, для такого-то простого запроса?), то что-то вроде:
%%(php)
if ($categories) {
  $ph = '?'.str_repeat(', ?', count($categories) - 1);
  DB::select('SELECT * FROM categories WHERE category_id IN  ('.$ph.')', $сategories);
}
%%

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

Не в сети

#5 15.11.2016 10:43:09

Re: Select..in(). Сырые запросы против ORM

Я когда писал свой ответ твоего ещё не видел, а так да.

Не в сети

#6 15.11.2016 11:45:42

Re: Select..in(). Сырые запросы против ORM

hzone пишет:

у меня любой сырой запрос === увольнение.

Отзываю свое резюме. Но поинтересуюсь: а за что такого страшного в старом добром SQL?

Как-то вот заметил я, что  ОРМ-ы приходят и уходят, а мой (почти) ровесник остается.

Не в сети

#7 15.11.2016 12:10:51

Re: Select..in(). Сырые запросы против ORM

  1. Но поинтересуюсь: а за что такого страшного в старом добром SQL?

В том, что где сырой запрос, там и SQL injection. Что мешает вопрошающему вместо моего кода

PHP
if ($categories) {
  
$ph '?'.str_repeat(', ?'count($categories) - 1);
  
DB::select('SELECT * FROM categories WHERE category_id IN  ('.$ph.')'$сategories);
}

использовать «оптимизированную версию»

PHP
if ($categories) {
  
DB::select('SELECT * FROM categories WHERE category_id IN  ('.join(', '$сategories).')');
}

?

  1. Как-то вот заметил я, что ОРМ-ы приходят и уходят, а мой (почти) ровесник остается.

А возраст не гарантия, скорее наоборот. Не так давно у eBay (тоже возраст огого) нашли SQL injection. Тоже, поди, ORM приходили и уходили, а сырые запросы с дырой оставались.

Не в сети

#8 15.11.2016 12:16:22

Re: Select..in(). Сырые запросы против ORM

tmanager пишет:
hzone пишет:

у меня любой сырой запрос === увольнение.

Отзываю свое резюме. Но поинтересуюсь: а за что такого страшного в старом добром SQL?
Как-то вот заметил я, что  ОРМ-ы приходят и уходят, а мой (почти) ровесник остается.

Ну, базист, конечно же, не понял бы :-)
Видимо, имелось ввиду, что увольняют именно за незнание ORM, что, в некоторых случаях, вполне логично выглядит.
Правда, не совсем понятно, отчего так сурово, особенно, с учетом того, что кандидат на увольнение аж умеет писать сырые запросы?
Не проще ли ему пару ссылок дать? Я так, из интереса.

Не в сети

#9 15.11.2016 12:24:45

Re: Select..in(). Сырые запросы против ORM

Proger_XP пишет:

Не так давно у eBay (тоже возраст огого) нашли SQL injection. Тоже, поди, ORM приходили и уходили, а сырые запросы с дырой оставались.

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

Не в сети

#10 15.11.2016 12:34:06

Re: Select..in(). Сырые запросы против ORM

tmanager пишет:

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

Ну какие там значительные ограничения? :-) Вы, простите, что, биллинг для МТС пишете? :-)

Не в сети

#11 15.11.2016 12:38:19

Re: Select..in(). Сырые запросы против ORM

Androbim пишет:

Ну какие там значительные ограничения? :-)

Не знаю.

Я понимаю, что ignorantia non est argument. Просто чует сердце-вещун: должны быть серьезные ограничения.

Вот изучу (куда деваться) этот ОРМ - и, может, продолжу эту тему.

Не в сети

#12 15.11.2016 12:56:35

Re: Select..in(). Сырые запросы против ORM

tmanager пишет:

Просто чует сердце-вещун: должны быть серьезные ограничения.

Ну, может и есть... Знаете, есть такие запросы, на пару страниц.... Но здесь же web-ремесленники, а не программисты баз данных. И hzone тут в своем праве - есть некие стандарты, а не "мне так удобнее, потому что я это знаю, а учиться не хочу".

Не в сети

#13 15.11.2016 13:02:09

Re: Select..in(). Сырые запросы против ORM

Androbim пишет:

"мне так удобнее, потому что я это знаю, а учиться не хочу".

Так вопрос не стоит.

Я начинаю изучать ОРМ - и думаю, мои аргументы не заставят себя ждать. Понадобится какой-нибудь SELECT ... INTO или что-то другое, чего не выразить ОРМ-ом.

А пока умолкаю за отсутствием аргументов.

Не в сети

#14 15.11.2016 14:40:03

Re: Select..in(). Сырые запросы против ORM

tmanager пишет:

Отзываю свое резюме. Но поинтересуюсь: а за что такого страшного в старом добром SQL?

Как-то вот заметил я, что  ОРМ-ы приходят и уходят, а мой (почти) ровесник остается.

Читаемость кода, стоимость разработки и поддержки проекта. Ты пробовал читать чей-то сложный запрос в БД? Сколько у тебя времени уходит на то, чтобы понять как это работает? Вот ты оставил время и энергию (т.е. деньги заказчика), разобрался, добавил фичу/пофиксил баг и забыл. Через три месяца лезешь в этот запрос и опять приходится разбираться полностью с нуля.

Еще ситуация. Ты изменил в одном месте код запроса и у тебя рухнуло отображение данных в нескольких местах. А вот работа с коллекциями стандартизирована. Ты можешь взять чужой проект и с ходу работать с данными, потому что всегда знаешь какой там будет формат данных.

Эту проблему можно частично решить репозиториями (без них простыни сырого SQL - это вообще говнокод), но это, по своей сути, создание своей недо-ORM. Зачем изобретать велосипед, когда уже есть готовые, протестированные и универсальные решения?

В ORM все эти проблемы сведены до минимума. Здесь читаемость на высоте, потому что код - почти предложения на английском.

Если честно, я вообще не понимаю как в 2016ом можно до сих пор писать сырые запросы при наличии прекрасных проверенных годами ORM.

Вообще, чтобы понять разницу между ООП и процедурным кодом, ORM и сырым SQL нужно сделать хотя бы один действительно сложный проект с множеством связей. Чем сложнее проект, тем разница более заметна.

На StackOverflow часто вижу вопросы от новичков с простынями сырого SQL (в основном - это индусы) и никогда желания в это лезть и помогать нет. И им почти никто не пытается помочь, потому что человек сам не понимает что в его коде происходит и не пытается понять. Его задача - сделать и забыть, о читаемости и поддержке кода он не думает вообще.

Изменено AlexeyMezenin (15.11.2016 14:44:55)

Не в сети

#15 15.11.2016 14:49:08

Re: Select..in(). Сырые запросы против ORM

AlexeyMezenin пишет:

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

Точно. Причем сделать не самому, а чтобы за него сделали. Задать вопрос и дождаться ответа. Работает - и ладно.

Не в сети

#16 15.11.2016 15:00:14

Re: Select..in(). Сырые запросы против ORM

Переименовал тему.

  1. Здесь читаемость на высоте, потому что код — почти предложения на английском.
  2. Вообще, чтобы понять разницу между ООП и процедурным кодом, ORM и сырым SQL нужно сделать хотя бы один действительно сложный проект с множеством связей. Чем сложнее проект, тем разнциа более заметна.

У каждого свои аргументы, и на мой взгляд эти — не основные. SQL значительно более «предложение на английском», чем код на ORM. SQL в конце концов стандартизирован, а разные ORM имеют разную форму записи, имена методов и так далее. Даже у разных версий Laravel есть отличия.

Поэтому сложные запросы как раз куда лучше писать в чистом SQL — это всякие INSERT... ON DUPLICATE KEY UPDATE, CREATE... SELECT, сложные SELECT с HAVING и тому подобное. Обычно, кстати, эти запросы нестандартны и работают только в MySQL (PgSQL, …), поэтому ORM их не поддерживает.

Но таких запросов мало, в основном работаешь с обычным «найти по дате и вернуть три поля из последних 10 записей». Для этого использовать SQL не нужно, т.к. действительно читаемость падает, ибо SQL в коде мало отличается от HTML или JS, или CSS.

Из стандартизированности и прозрачности SQL вытекает и то, что чем больше проект, тем больнее ощущаются уровни абстракции. Модели, ORM — лишний уровень. Да, необходимый. Но это ни разу не упрощает вхождение в такой проект, хотя, если грамотно написано, может упростить его понимание. Но спорно.

Основная проблема — это безопасность. Я аж в ступор впал, когда прочитал «…за незначительное усиление надежности». SQLi были бичом сети вплоть до последнего времени. Это тот же buffer overflow в Си, только SQLi удалось побороть благодаря распространению ORM, а переполнение буфера до сих пор то и дело вылазит в новых проектах. Сырые запросы приводят к огромным проблемам, если их использует не какой-нибудь ветеран, который может держать огромный проект целиком в голове и точно знать, где может просочиться пользовательский ввод. Но стоит ему уйти, придёт обычный разработчик и вся безопасность пошла-поехала, т.к. тут у него экранирование забыто, там строка проскочила и привет — у топового интернет-аукциона находят SQLi на главной странице. И утекли миллионы данных пользователей, потому что их разработчик считал «незначительные улучшения надёжности» выше своего достоинства.

Каждый сырой запрос — это потенциальная дыра. Сколько запросов — столько дыр. По статистике вероятности после …цатого запроса помноженное на число доработок проекта и членов команды вероятность ошибки стремиться к единице. Оно вам надо?

Не в сети

#17 15.11.2016 15:29:25

Re: Select..in(). Сырые запросы против ORM

AlexeyMezenin пишет:

Читаемость кода, стоимость разработки и поддержки проекта. Ты пробовал читать чей-то сложный запрос в БД? Сколько у тебя времени уходит на то, чтобы понять как это работает?

Запрос SQL - это предложение на английском языке. И если он тяжело читается - значит, плохо спроектирована база и/или автор запроса неправильно строит работу с базой. На мои сложные запросы никто не жалуется.

AlexeyMezenin пишет:

Вот ты оставил время и энергию (т.е. деньги заказчика), разобрался, добавил фичу/пофиксил баг и забыл. Через три месяца лезешь в этот запрос и опять приходится разбираться полностью с нуля.

Если я "разобрался и пофиксил" - значит, запрос переписан и читается как "я помню чудное мгновенье".

AlexeyMezenin пишет:

Еще ситуация. Ты изменил в одном месте код запроса и у тебя рухнуло отображение данных в нескольких местах.

Если мне за это объявят неполное служебное соответствие - я скажу, что счастливо отделался.

AlexeyMezenin пишет:

Ты можешь взять чужой проект и с ходу работать с данными, потому что всегда знаешь какой там будет формат данных.

Вот взял. Бьюсь, как рыба об лёд.

Кстати, уже могу назвать проблему, к которой привел ORM. Человек писал код, совершенно не заморачиваясь быстродействием. Индексы, партишины, view? Нет, не слышали. Все записи в массив, массив обойдем построчно, собирая чего-то там. Потом и о пагинации подумаем, если процесс еще не гавкнулся...

AlexeyMezenin пишет:

Если честно, я вообще не понимаю как в 2016ом можно до сих пор писать сырые запросы при наличии прекрасных проверенных годами ORM.

Ну хотя бы затем, чтобы легче понять, в чем проблема выполнения запроса. Вот не работает правильно код ORM - что ему, скоту, надо???
А выводишь текст запроса, который тщится выполнить скрипт - и "вот и он, больной зуб"

AlexeyMezenin пишет:

Вообще, чтобы понять разницу между ООП и процедурным кодом, ORM и сырым SQL нужно сделать хотя бы один действительно сложный проект с множеством связей.

Этого у меня не отнять.

Не в сети

#18 15.11.2016 15:38:23

Re: Select..in(). Сырые запросы против ORM

Proger_XP пишет:

Основная проблема - это безопасность. Я аж в ступор впал, когда прочитал "...за незначительное усиление надежности". SQLi были бичом сети вплоть до последнего времени.

Все известные мне (не по прессе, а от верных людей) взломы были делом рук людей, законно получивших все необходимые доступы для своего злодейства. Им не нужно было унижаться до SQL-инжекции.

Proger_XP пишет:

и привет - у топового интернет-аукциона находят SQLi //на главной странице//. И утекли миллионы данных пользователей, потому что их разработчик считал "незначительные улучшения надёжности" выше своего достоинства.

Не поэтому. А потому, что он вообще ничего не считал. Это такая примета времени сегодня - "эффективный менеджер". Он - руководил.
Дал команду.

Proger_XP пишет:

Каждый сырой запрос - это потенциальная дыра. Сколько запросов - столько дыр. По статистике вероятности после ...цатого запроса помноженное на число доработок проекта и членов команды вероятность ошибки стремиться к единице. Оно вам надо?

Мне - не надо. Я просто взял за правило экранировать все, что пихаю в запрос.

Не в сети

#19 15.11.2016 15:41:12

Re: Select..in(). Сырые запросы против ORM

Proger_XP пишет:

SQL значительно более "предложение на английском", чем код на ORM

А ты сравни запрос с десятком отношений с eager loading и сырой запрос. Предложение на английском VS тарабарщина с использованием английских слов.

SQL в конце концов стандартизирован, а разные ORM имеют разную форму записи, имена методов и так далее. Даже у разных версий Laravel есть отличия.

Я говорил о формате данных. При использовании сырых запросов каждый изобретает велосипед. Даже если используется массив, то структура массива у каждого человека разная. Коллекции же выдаются всегда стандартные.

SELECT с HAVING

Ты под сырыми SQL запросами имеешь ввиду Query Builder или все-таки сырые запросы?

Но таких запросов мало, в основном работаешь с обычным "найти по дате и вернуть три поля из последних 10 записей". Для этого использовать SQL не нужно, т.к. действительно читаемость падает

Мое мнение - как раз наоборот. При простых запросах вообще разницы ноль: сырой SQL или ORM. А вот при сложных - ORM выгодно отличается.

Не самый удачный пример, наглядно показывающий читаемость ORM и SQL, но что под рукой есть:

$this->where('id', $id)
     ->slug($slug)
     ->with([
         'publications' => function($q) {
             $q->where('verified', true);
         },
         'verifiedLanguages',
         'countries',
         'publications.tags'
     ])->first();

Генерирует вот это:

select * from `users` where `id` = '4' and `slug` = 'John-Smith' and
 `users`.`deleted_at` is null limit 1

select * from `publications` where `publications`.`user_id` in ('4')
 and `verified` = '1'

select `tags`.*, `publication_tag`.`publication_id` as `pivot_publication_id`,
 `publication_tag`.`tag_id` as `pivot_tag_id` from `tags` inner join
 `publication_tag` on `tags`.`id` = `publication_tag`.`tag_id` where
 `publication_tag`.`publication_id` in ('3', '4', '5', '6', '7', '9',
 '12', '16', '17', '18', '20', '21', '22')

select `languages`.*, `language_user`.`user_id` as `pivot_user_id`,
 `language_user`.`language_id` as `pivot_language_id`, `language_user`.`id`
 as `pivot_id`, `language_user`.`verified` as `pivot_verified`,
 `language_user`.`evidence_text` as `pivot_evidence_text`, `language_user`.`proficiency`
 as `pivot_proficiency`, `language_user`.`created_at` as `pivot_created_at`,
 `language_user`.`updated_at` as `pivot_updated_at` from `languages`
 inner join `language_user` on `languages`.`id` = `language_user`.`language_id`
 where `language_user`.`verified` = '1' and `language_user`.`user_id` in ('4')

select `countries`.*, `country_user`.`user_id` as `pivot_user_id`,
 `country_user`.`country_id` as `pivot_country_id` from `countries`
 inner join `country_user` on `countries`.`id` = `country_user`.`country_id`
 where `country_user`.`user_id` in ('4')

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

Это просто пример, который под рукой. Если здесь использовать полиморфные связи, работу с дополнителными полями в pivot и т.д., SQL будет выглядеть еще более нечитаемо.

Не менее важный момент: ORM запрос выше создает одну коллекцию с вложенными коллекциями и "пройтись" в представлении по всем данным - одно удовольствие. Если человек напишет сырой запрос, подобный показанному выше, почти всегда это будет отсебятина в виде nested массивов с неведомой структурой.

И еще плюсики в сторону Eloquent. Он на лету работает с датами как с Carbon объектами, Soft Deletes и прочими стандартными фишками, которые нужно создавать и поддерживать руками при использовании сырых запросов. А еще есть события, scopes, геттеры и сеттеры и пр. вкусности. )

Изменено AlexeyMezenin (15.11.2016 15:55:31)

Не в сети

#20 15.11.2016 15:43:27

Re: Select..in(). Сырые запросы против ORM

tmanager, я правильно понимаю, что вся логика Ваших сообщений на форуме сводится к "нафиг нужны эти ORM, MVC, Laravel, если и без них было хорошо"?

Изменено Androbim (15.11.2016 15:44:10)

Не в сети

#21 15.11.2016 15:47:04

Re: Select..in(). Сырые запросы против ORM

Кстати, уже могу назвать проблему, к которой привел ORM. Человек писал код, совершенно не заморачиваясь быстродействием. Индексы, партишины, view? Нет, не слышали.

Логика на уровне "новичок написал проект через зад с использованием ORM, значит ORM гомно"...

На счет индексов - я ни в одном проекте пока еще не собирал JS/CSS, не создавал индексы и пр. только потому, что никто не хочет за это платить, заказчики сами делают эти мелочи при тестировании приложения. Возможно, у тебя та же ситуация. Может и нет.

Вот не работает правильно код ORM - что ему, скоту, надо?

Может изучить ORM до той степени, чтобы понимать как это работает? У меня, когда ORM работает "не так", я смотрю в документацию, исходники Laravel и свой код, а не в сырые запросы. Да и смотреть в сырые запросы, генерируемые ORM - это совсем не то же самое, что писать приложение с использованием сырых SQL запросов.

Не в сети

#22 17.11.2016 20:39:36

Re: Select..in(). Сырые запросы против ORM

Я всего лишь спросил совета, как мне в сыром запросе адекватно вставить переменную в условие IN().

Proger_XP, спасибо, такое предложение в инете встречал, но думал, что есть что-то типа плейсхолдеров, как в некоторых библиотеках работы с бд))

В моем случае, это первое знакомство с laravel, проект большой, но не биллинг для мтс, как кто-то упомянул.
Проект веду я один и поддерживать его буду я, а если после меня кто-то залезет в код не составит никакиех трудов в нем разобраться ибо каждый запрос обернут в функцию, название которой говорит само за себя. Не считаю это каким-то "непрофессионализмом" или чем-то другим. Сложно мне начать с ORM сразу на боевом проекте, все эти связи.. Я себя чувствую ограниченным в движениях. Работаю с postgres , есть выборки по json, массивам со сложными условиями.
Было сказано про "сырой запрос === увольнение". Иными словами, если ты рисуешь зеленым карандашом, ты не сможешь работать с нами над картиной пустыни, потому что мы рисуем синими карандашами. hzone, ты по многим моим топикам давал подсказки по laravel и спасибо большое. Но, как было бы полезнее провести своей команде мастер-класс и вывести на должный уровень, что делает руководителя, хорошим wink

Масса людей пользуется ORM и конструкторами и мало понимает вообще как оптимизируется сам запрос. Дискуссий в интернете полно по сырым запросам и ORMам. Есть плюсы и минусы, каждый выберет подходящий вариант. Говнокод, вообще понятие субъективное по большинству своему, ибо это первое, что вы гворите, видя проект предыдущего программиста)

В доках ларавеля, есть текст для сырых запросов:
"Привязка параметров обеспечивает защиту от SQL-инъекций." Так как правильно считать, обеспечивает, но не так сильно как хотелось бы?

Изменено Fridz (17.11.2016 20:40:21)

Не в сети

#23 17.11.2016 22:48:11

Re: Select..in(). Сырые запросы против ORM

  1. В доках ларавеля, есть текст для сырых запросов:
  2. «Привязка параметров обеспечивает защиту от SQL-инъекций.» Так как правильно считать, обеспечивает, но не так сильно как хотелось бы?

Обеспечивает, но грань между сырым запросом с параметрами (безопасно) и сырым запросом без параметров (опасно) очень тонка. Выше я приводил пример, к чему может привести именно использования select..in без понимания разницы между параметрами и самим запросом.

  1. Но поинтересуюсь: а за что такого страшного в старом добром SQL?

В том, что где сырой запрос, там и SQL injection. Что мешает вопрошающему вместо моего кода

PHP
if ($categories) {
  
$ph '?'.str_repeat(', ?'count($categories) - 1);
  
DB::select('SELECT * FROM categories WHERE category_id IN  ('.$ph.')'$сategories);
}

использовать «оптимизированную версию»

PHP
if ($categories) {
  
DB::select('SELECT * FROM categories WHERE category_id IN  ('.join(', '$сategories).')');
}

?

Я надеюсь, проблему во втором запросе видно без комментариев?

Не в сети

#24 18.11.2016 01:22:22

Re: Select..in(). Сырые запросы против ORM

потехоньку разговор от темы скатывается к стоимости разработки, стоимости поддержки, и стоимости зелёнки от тумаков заказчика )))

объясните парню проще, например - попробуй забить 200 гвоздей в срок 1 час без молотка (инструмента, по аналогии ларавела).
- за 30 минут сломаешь руки, ноги и другие крепкие части тела
- за 29 минут заточешь камень
- работать тебе 1 минуту и дедлайн.
= потерял выгоду.
но всё равно делаь будешь, ибо договор.
и тут уже наступает момент потери твоего времени, которое при использовании молотка, ты мог бы потратить или на другого клиента или на трату полученной выгоды в угоду себе = это уже стоимость неустойки, равная стоимости получени очередной выгоды от нового клиента в период работы на старого клиента.
понятно объясняю?
а ведь ещё баги ловить, тестить, запускать в продакшен, обязательно всплывёт "ой забыл" от клиента или не дай бог от тебя...

ещё пример: струйные принтеры HP
- принтер стоит копейки.
- набор чернил в годовом эквиваленте = 5 принтерам (в зависимости)

это яркий пример-аналогия стоимости работы и стоимости вынужденной поддержки. одно без другого бессмысленно. а в сумме жаба душит smile

Изменено hzone (18.11.2016 01:24:02)

Не в сети

#25 22.11.2017 08:11:08

Re: Select..in(). Сырые запросы против ORM

Добрый день.
Решил не создавать новых тем. Только начал изучат Laravel и возник затык при переводе своих "старых" sql запросов в "ларавель правильные"
Вот один из
SELECT a.answer_id, at.type, a.value, ao1.type_other, ao1.other_value, ai.value as image, a.hidden, a.required
FROM answer a
    LEFT JOIN answer_type at ON (a.answer_type_id = at.answer_type_id)
    LEFT JOIN answer_image ai ON (a.answer_id = ai.answer_id)
    LEFT JOIN ( SELECT at.type as type_other, question_id,answer_id, value as other_value
                FROM answer_other ao JOIN answer_type at ON (ao.answer_type_id = at.answer_type_id)
                WHERE ao.question_id = (int)$question_id
              ) ao1 ON (a.answer_id = ao1.answer_id)
WHERE a.question_id = (int)$question_id
ORDER BY a.sort_order
Как наиболее правильно это сделать? На ум приходит только raw.

Не в сети

Подвал раздела