Можно ли составить mysql запрос с выборкой не определенного множества полей?

Question

[RuRoman]

В сложных выборках не силен, поэтому вопрос
К примеру есть 3 таблицы

1таблица "товар"
id
name - Название
desc - Описание

2таблица "Свойства"
id
name - Название свойства

3таблица "свойства товара"
id_prod - ID товара
id_prop - ID свойства
val - значение

У каждого товара может быть любое количество свойств, разное.

Можно ли одним запросом вывести все товары и свойства которые соответствуют данному товару
id товара, название, свойство, значение......все свойства, значения.

1; Ручка; Цвет; Синий; Цена; 10
2; Нож; Материал; Цена; 200; Рукоятка; Дерево; Фото; Есть;

Comments

[Everything_is_bad]

это вообще простой запрос, подтягивай основы sql
эта модель называется EAV, в чистом виде у нее проблемы с производительностью, поэтому использую различные способы денормализации

[Everything_is_bad]

так MySQL или MariaDB? зачем ты два тега поставил?

[hint000]

Старые вопросы на ту же тему:

Как хранить свойства товаров разного рода?

Как в БД делают возможность разделять какой-то продукт по цветам и размерам в наличии?

Какую структуру таблиц выбрать для описания некоторой сущности, у представителей которой часть атрибутов совпадает, а часть — различна?

Answer 1

[Roman]

Можно https://www.w3schools.com/mysql/mysql_join.asp

Answer 2

[Rsa97]

JOIN, GROUP_BY, JSON_OBJECTAGG, JSON_ARRAYAGG

Answer 3

[alexalexes]

Можете, но свойства будут не в пределах строки (горизонтально), а в пределах колонки (вертикально).
С помощью SQL вы можете, не забивая микроскопом гвозди, извлечь вот такой результат:

Ручка; Цвет; Синий;
Ручка; Цена; 10
Нож; Материал; Дерево;
Нож; Цена; 200;
Нож; Рукоятка; Дерево; 
Нож; Фото; Есть;

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

Comments

[RuRoman]

В том то и дело что мне нужно в пределах строки, потому что если в пределах колонки - то учитывая что товаров может быть больше 100К и у каждого по 30-200 свойств, получается очень огромных маштабов выборка

[alexalexes]

Объем данных таблицы тут ни причем, для обычного join это вообще типовая выборка.
Вы никогда не будете явно выбирать 100К.
Либо выборка будет происходить в пределах одного товара, либо в пределах страницы в 10, 50, 100 товаров.
Во всех этих случаях, если правильно создать индексы на колонках "свойства товара".id_prod и "свойства товара".id_prop, то запрос с join-инами будет всегда легковесным.

Answer 4

[otdameskapizm]

Вам нужно объединить 2 таблицы (Товары, Свойства) через отношения, которые даны у вас в таблице (Свойства товаров).

Возможно написать что-нибудь в таком стиле (но это просто, как пример, он может для Вас не подойти):

SELECT 
    item_name,
    GROUP_CONCAT(prop_value) AS props
FROM
	(  
    SELECT 
        l.name AS item_name,
        r.name AS prop_name,
        z.val AS prop_value
    FROM 
        items AS l
        INNER JOIN 
        props_to_items AS z
        ON 
        l.id = z.item_id
        INNER JOIN 
        props AS r
        ON
        z.prop_id = r.id
	) AS total_info
GROUP BY 
	item_name

Что выведет в результате вот такое:

| item_name | GROUP_CONCAT(prop_value) |
| --------- | ------------------------ |
| item_1     | Prop_1,Prop_2,Prop_3.    |
| item_2     | Prop_1,Prop_2,Prop_3     |

---

Answer 5

[Akina]

Можно ли одним запросом вывести все товары и свойства которые соответствуют данному товару
id товара, название, свойство, значение......все свойства, значения.

1; Ручка; Цвет; Синий; Цена; 10
2; Нож; Материал; Цена; 200; Рукоятка; Дерево; Фото; Есть;

Приведённый хреново форматированный текст не позволяет понять, где какое поле, и какой в нём тип данных.

Полное ощущение, что автору требуется куча колонок (в смысле полей в структуре выходного набора). ТО есть если свойство одно, полей 4, если свойств 2, полей 6, и так далее...

Если так, то требуемый результат называется "сводная таблица" (pivot table). Это совсем даже не реляционная структура, у которой нет и тени шанса попасть в стандарт, а потому практически ни одной СУБД штатно не поддерживается. Из популярных оно есть исключительно в SQL Server, да и там скорее исторически сложилось, чем нужно было.

В MySQL / MariaDB ничего подходящего нет. И если кому оно реально необходимо, приходится возиться руками - хранимая процедура, динамический код... хотя на порядок разумнее оставить данные в EAV, а сводную таблицу строить на клиенте на его сервисе отчётов.

Если же устроит выдача всех свойств, собранных в одно сериализованное поле (например, объект JSON) - то это обычная группировка и агрегация.