lexstile, ну смысл такой. в mysql 8, и postgres можно приджойнить значения. например для мускула
select
sum(dishes.price*prices.quantity)
from
dishes
join (VALUES ROW(5,100), ROW(10,600)) AS quantities(dishe_id, quantity)
on quantities.dishe_id = dishes.id;
lexstile, нет конечно. Никакой in() порядок не сохраняет, для указания порядка используется order by. Все остальное будет возвращать так как бд удобнее. Однако что мешает запихнуть в order by сортировку на основе позиции в списке
Михаил Ливач, ну если у нас в среднем товаров от двух и больше на n можно не надеятся.
Итого. Алгоритм мердж джоин сложности не представляет, работает он быстрее и без дополнительных трат в виде дополнительных массивов и прочего. Упование на то что кому то он может показаться сложным и кто то его не осилит - критики не выдерживает. Засим предлагаю закрыть тему
Михаил Ливач, я прекрасно понимаю что такое поддержка проекта. И хорошо представляю что надо постараться что бы написать цикл с одним ифом так что бы он был не понятен, без вопросов возможно - но надо стараться. А учитывая что разговор идет о фреймоворке Laravel то я вообще добавлю это как метод класса Collection и будет что нибудь типа
$dishesRequest->mergeJoin('id', function($item1, $item2){ код мерджа}, $dishes);
Да и через array_walk это делается легко и понятно.
в 2 прохода не играет роли.
Угу. Это если у вас этот код выполняется раз в сутки. А если 100 раз в секунду это будет уже не так весело.
Михаил Ливач, этот алгоритм прекрасен когда у нас оба массива отсортированы, какая разница какие обьемы? Вместо вложенных циклов - 1. O(n^2) и O(n)
Здесь я сортировку вижу - следовательно это первая мысль. Если ее нет - то стоит посмотреть в сторону hash join если массивы можно получить где id будет ключом - массивы в php это хеш таблицы и следовательно будет из коробки.
Зачем вам 2 цикла, если данные отсортированы и у нас есть 100 уверенность что каждому id в одном массиве есть соответствие в втором. Одним циклом идете и смещаете позицию для обоих массивов
lexstile, да смысл считать. И так понятно что и по памяти и по скорости selectRaw будет быстрее. Ибо оверхеад на передачу хранение и несколько обходов. Стоит избавляться от не любви к selectRaw
lexstile, ну только в вашем случае база передает вам записи, которые пихаются в массив и потом вы его еще обходите обсчитываете. в моем уже готовый результат. Вы уверены что ваша процедура менее ресурсоемкая, и трата этих ресурсов оправдана тем что вам не нравится selectRaw? Я то вот как то сильно не уверен
