6

Есть таблица с характеристиками товаров и столбцами Good_ID, Field_ID, Value. Может быть сколько угодно записей с одним Good_ID и разными Field_ID и Value.

Field_ID - это идентификатор определенной характеристики

Нужно написать запрос, чтобы выбирались Good_ID, которые удовлетворяют нескольким парам Field_ID и Value. По сути фильтрация по характеристикам товара.

Не могу придумать, как одним запросом выбрать из таблицы все товары, у которых цвет синий и вес до 1кг.

Обновление

Всем спасибо. В общем в итоге получилось реализовать вот так 

SELECT DISTINCT Good_ID FROM chars WHERE 
Message_ID IN (SELECT Good_ID FROM chars WHERE  Field_ID = 3 AND Value = 'серый')
AND   Message_ID IN (SELECT Good_ID FROM chars WHERE  Field_ID = 2 AND Value = '3')

Если я не правильно составил запрос - поправьте плз.

Nicolas Chabanovsky
  • 51,426
  • 87
  • 267
  • 507
Николай Новиков
  • 75
  • 7

2 Answers2

5

У Вас должна быть таблица со списком товаров. Типа goods. Т.е. Good_ID это id из этой таблицы.
Далее, предположим, что:

  • Ваша таблица с характеристиками называется attributes.
  • Field_ID для цвета = 1
  • Field_ID для веса = 2

Тогда нужный Вам запрос будет выглядеть так:

SELECT g.* FROM goods g
JOIN attributes aCo AS g.id=aCO.Good_ID AND aCo.Field_ID=1 AND aCo.value='синий'
JOIN attributes aW AS g.id=aW.Good_ID AND aW.Field_ID=2 AND aW.value=1

Этот запрос покажет Вам все товары из таблицы goods, у которых цвет (Field_ID=1) синий, а вес (Field_ID=2) = 1.

У меня на сайтах реализована описанная Вами схема, поэтому позволю себе дать Вам совет: будет лучше, если Вы сделаете сводную таблицу всех товаров и их аттрибутов. Можно туда добавить другую информацию: цены, описания, названия, картинки...

Что-то типа такого:

Good_ID  SKU         title                    price   a1    a2  a3  
-------  ---------   ---------------------    ------  ---   --- ---
      2  [артикул]   [наименование товара]    450.00  red   3   45
    452  [артикул2]  [наименование товара 2]   15.00  white 5   64

a1, a2, a3 - это значения аттрибутов 1, 2 и 3 (у Вас Field_ID).
В зависимости от того, как часто меняется информация о товаре можно такую таблицу генерировать заново раз в час / несколько часов / раз в сутки.

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

Очень советую.

cyadvert
  • 7,015
  • тоже была необходимость фильтровать подобным образом, join работал как то медленно, сделал при помощи union, т.е. select необходимые поля from table where условие union следующее условие и последующей группировки. за создания таблицы отдельное спасибо – Bald Dec 28 '15 at 04:42
  • К сожалению не возможности изменять таблицу, так как проект боевой и стоит задача только доставать информацию из существующей таблицы. Интересно, когда будет сразу фильтроваться по 20-ти характеристикам не будет join подтормаживать? – Николай Новиков Dec 28 '15 at 07:14
  • много join скорее всего будут тормозить. возможно join с (select 1,'синий' from DUAL union select 2,'1' from DUAL) и посчитать количество совпадений по каждой id (в общем похоже на идею из второго ответа) будет быстрее, а может и нет. В зависимости от данных. И автор данного ответа предложил не менять структуру существующей таблицы, а сделать кеш-таблицу, которую формировать время от времени. надо только посмотреть сколько времени она формироваться будет – Mike Dec 28 '15 at 07:51
  • @Bald56rus запрос с UNION мне почему-то отдает Good_ID так если бы в обычном запросе просто поставить OR т.е. и синий цвет и вес 1кг в результатах, но так же и черный цвет и вес 1 кг например – Николай Новиков Dec 28 '15 at 08:01
  • Чем больше join, тем больше будет притормаживать. А если Вам понадобиться делать LEFT JOIN, то будет еще хуже. Как быстрее, с UNION или без Вам придется проверять самому - зависит от фильтрационных данных, размера таблицы. – cyadvert Dec 28 '15 at 08:13
  • @Mike у меня кое-где такая таблица генерируется аж 5 минут. Аттрибутов много, плюс много других параметров я вношу в таблицу. У меня две кэш-таблицы. Одна "рабочая", вторая "живая". Они идентичны. Сайт всегда пользуется лишь "живой" таблицей. А вся основная работа по генерации происходит в "рабочей". Когда процесс закончен, одним запросом INSERT INTO ... SELECT я переношу данные из "рабочей" в "живую". Имея такую структуру мне не очень важно, сколько времени занимает регенерация - посетители этого не замечают... – cyadvert Dec 28 '15 at 08:21
  • @cyadvert Я бы при долгой генерации, в триггерах на таблицу с основными данными писал бы в отдельную таблицу id записей по которым были изменения и перегенерил бы кеш только для них. – Mike Dec 28 '15 at 08:43
  • @Mike, да, хороший вариант. Только я делал не на триггере, а с использованием поля dateUpdated TIMESTAMP, сравнивая ее с датой последней регенерации. Впрочем, тут несколько вариантов... :) Лишь бы работало :) – cyadvert Dec 28 '15 at 15:12
1

Что-то похожее на это, можно попробовать:

SELECT Good_ID FROM table 
WHERE (Field_ID in(идентификатор цвета, идентификатор веса) 
AND (Value=параметр отвечающий за синий or Value<=1)) 
GROUP BY Good_ID 
HAVING Count(*)=2
Nick Volynkin
  • 34,094
LamerXaKer
  • 687