Mysql Выбрать товары и цены одним запросом с группировкой по товару

[Valick]

не вижу смысла спорить, ну чес слово

так я и не спорю, если ты не заметил
ты на ровном месте вбил себе в голову, что я не знаю о сущностях, ОРМ и прочем исключительно на основании того, что я не пишу об этом новичку на форуме

 

[WMix]

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

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

 

[Valick]

структура исключительно для обхода двумя форычами и вывода "как есть"
проще там уже некуда

 

[Slon747]

Я вам об этом с самого начала говорил, откуда мне было знать, что вы настолько "учёный", что не понимаете слова и вам надо написть готовый код?

Ну и при чем тут php, когда мой ответ был на реплику "учитесь грамотно организовывать стркутуру таблиц, учите правила нормализации" ?

 

[Slon747]

что такое большой? сколько товаров на странице? 100? и допустим по 10 цен на товар... много. но не критично, если больше, то вероятнее всего чтото делаешь не так

hashtable на 1000 строк, не более 3х тактов процессора обычно говорят о сложности O(1)

Нет задачи выводить данные на страницу. Требуется выгрузить все товары в JSON-формате.
Можно, конечно, выгружать отдельно товары и цены в отдельных файлах, тогда все просто.
Это другой вариант. В обоих вариантах есть свою плюсы и минусы.

 

[Valick]

Дальше уже срадствами РНР фомируете тебуемый вид.

Ну так и надо было сразу сказать, что эта фраза непонятна. Я же не экстрасенс

 

[Valick]

Требуется выгрузить все товары в JSON-формате.

замени в моём коде print_r($result); на echo json_encode($result);

 

[WMix]

все товары в JSON-формате

и сколько этих записей будет. сколько продуктов, сколько цен?

 

[Slon747]

и сколько этих записей будет. сколько продуктов, сколько цен?

Это зависит от желаний и возможностей пользователей.
У кого-то меньше, у кого-то больше.
Исходя из специфики приложения, вряд ли больше 5 тыс товаров и 5 типов цен.
Сами пользователи будут работать на мобильных устройствах и в идеале не замечать ту часть, которая для них будет "облаком" или изредка к ней обращаться.
Но это если вообще мой проект выстрелит)

 

[weregod]

Очередная торговая площадка что ли?

 

[WMix]

25к, будет критичной, когда параллельно спрашивать начнут (утром в 6 сайт виснет), но уже дофига, можно тоже чуток оптимизировать но не важно

 

[Slon747]

Очередная торговая площадка что ли?

Нет

 

[AnrDaemon]

Одного меня смущает выборка цен по типам на товары?…

P.S.
Реальный (псевдо)код:

<?php

/** @var mysqli $mysqli */
$stmt = $mysqli->prepare("SELECT * FROM data");
$stmt->execute();
$res = $stmt->fetch_all(\MYSQLI_ASSOC);
if (empty($res)) return [];

$list = array_column($res, 'id');
$stmt = $mysqli->prepare("SELECT * FROM tags WHERE component = ? AND component_id IN (" . join(', ', array_fill(0, count($list), '?')) . ")");
$stmt->execute(['data', ...$list]);
$tags = array_reduce($stmt->fetch_all(\MYSQLI_ASSOC), function ($carry, $tag) {
    $carry[$tag['component_id']][$tag['tag']] = $tag;
    return $carry;
}, []);

foreach ($res as &$item) {
    $item['tags'] = $tags[$item['id']] ?? new \ArrayObject;
}

return $res;

Два запроса на любое количество данных.

 

[WMix]

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

 

[AnrDaemon]

Там не 1:1, и не пара колонок на таблицу, так что заджойнить не вариант.
Тегов может быть десяток только технических, а в данных колонок около двадцати.
Встроить оригинальный запрос, конечно, вариант, но там уже устоявшийся DBAL, в который я лезть не хочу (реалистично это всё разнесено по трём функциям и несколько сложнее приведённого псевдокода).