Как вывести несколько значений с одним ID в диапозоне?

Question

[LieKarp]

Есть таблица заказов (orders):
id dishes
поле dishes имеет такой формат 1,2,2,5,1,2
Как можно вывести повторение значений с одним и тем же ID?
SELECT * FROM dishes WHERE id IN (1,2,2,5,1,2)
Выводит записи, но без повторений =(

Как можно вывести точно такой же результат, но с повторами ID 2, например?

Answer 1

[Олег]

лучше сделайте нужный вывод на PHP или на чем там у вас бакенд

через SQL получается слишком громоздно
select 1 as fictiv_number, field1,.., field2 from dishes where id=val1
union select 2 , field1,.., field2 from dishes where id=val2

или делать хранимую процедуру

Comments

[LieKarp]

Спасибо, делаю так

for (const dishId of item.dishes.split(',')) {
                        if (!dishId) continue;
                        dishes.push(await knex("dishes as dish")
                            .select([
                                "dish.id",
                                "dish.name"
                            ]).where({id: dishId}).first())
                    }

Но если слишком много блюд будет - то это много запросов и будет долгий отклик ))

[Олег]

Это питон ?
1.Выбери из массива уникальные идишники .
2.сделай запрос в базу
3.разложи ответ в массив по ид
4 в цикле по исходному массиву идишников
5 обращайся к массиву из п 3

[LieKarp]

Олег, это Javascript - так и сделаю, спасибо

[Олег]

LieKarp , стукнись в телегу . Взять ее можно в моем профиле на гитхабе . Сслыка на гит есть на хомяке . ссылка на хомяка в профиле тостера

Answer 2

[ThunderCat]

Как можно вывести точно такой же результат, но с повторами ID 2, например?

Если с самого начала проектировать бд в нормальной форме, а не то что получилось, то задача вполне нормально решается. Создается таблица отношений наборов к блюдам, и объединяется как многие ко многим, и всё будет нормально выбираться. А кажущаяся "оптимальность" хранения идентификаторов строкой в одном поле - ошибка почти всех новичков, тем не менее это отвратительная практика, рожденная некомпетентностью и ленью. Меняйте структуру, пока не поздно, на этапе разработки это сделать проще, чем когда уже внесете кучу данных в рабочий говнопроект. Делайте сразу хорошо, чтобы потом не страдать.

Comments

[LieKarp]

Примерно так получилось - это правильный вариант?))

[Олег]

LieKarp, НЕТ
Цены изменились на складе - архивные заказы - что ? - мусор
заказ это снимок товарной базы на момент оформления

Ид товара в дишес - это только удобный идентификатор - чтобы посмотреть срез продаж со склада
а вся информация для чека уже должна быть в этой строке (наименование/цена/скидка и прочее)

[ThunderCat]

LieKarp, ордер должен быть копией текущего товара, тут Олег абсолютно прав, у вас налету может измениться стоимость, но уже заказанный товар вы заказчику будете отдавать по стоимости на момент заказа. Ну и суммы в истории будут плясать естественно. Выглядит как дублирование, но это разные сущности. Кроме того, никто не исключает вариант что из товаров что-то удалится, тогда в базе будет вообще ерунда.