Mysql создание структуры бд для товаров с разными сущностями

[С.]

EAV -- удобный способ хранения такого рода данных. Никто не говорил, что он идеален для поиска по нескольким атрибутам. Я вижу это как группировку по признаку вхождения во множество искомых атрибутов и затем проверка на количество элементов в группе. Должно быть столько же, сколько ищется.

 

[С.]

Boris, если тебе надо именно стул из дерева с ножками из металла, в твоём варианте таблицы ты этого никак получить не сможешь.

Не надо так безапеляционно. Это можно сделать хотя бы тупым и неэффективным джойном на себя.

 

[Boris]

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

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

Я буду очень благодарен на ссылки или примеры
С уважением ко всем форум чанам , Борис!

 

[WMix]

id, product, attr, value
1, 1, столешница, дерева
2, 1, ножки, металические

select product from xxx 
where 
(attr = 'столешница' and  value = 'дерева') or 
(attr = 'ножки' and  value = 'металические') 
group by product 
having count(*) = 2

 

[AnrDaemon]

Не надо так безапеляционно. Это можно сделать хотя бы тупым и неэффективным джойном на себя.

Если товарищ создаёт таблицу "entity-value", он никак не сможет выбрать из неё "attribute" - его там просто нет!
WMix, зачем id? Это нормализатор, тут primary key product+attr, без всяких id.

 

[WMix]

AnrDaemon, не люблю двойной ключик. Места чтоль жаль?

 

[Активист]

@WMix правильно говорит, используйте having

Вот реальный пример
Картинка: тут
SQL такой:

select sql_calc_found_rows `app_catalog_item`.*, count(`app_catalog_item`.`id`) as matched
from `app_catalog_item`
left join `app_catalog_category` on `app_catalog_category`.`id` = `app_catalog_item`.`categoryId`
right join `app_catalog_filter_values`  on `app_catalog_filter_values`.`item` = `app_catalog_item`.`id`
where `app_catalog_item`.`public` = '1' and `categoryId` in ('420') and
(
    ( `app_catalog_filter_values`.`param`='14' and ( `app_catalog_filter_values`.`value` = '416' or `app_catalog_filter_values`.`value` = '92' ) )
    or
    ( `app_catalog_filter_values`.`param`='17' and (`app_catalog_filter_values`.`value` = '122' or `app_catalog_filter_values`.`value` = '136' ) )
)
group by `app_catalog_item`.`id`
having `matched` = '2'
order by `app_catalog_item`.`top` desc, `app_catalog_category`.`position`, `position`
limit 0, 51

explain
+----+-------------+---------------------------+--------+---------------------------------+---------+---------+------------------------------------------+------+-----------------------------------------------------------+
| id | select_type | table                     | type   | possible_keys                   | key     | key_len | ref                                      | rows | Extra                                                     |
+----+-------------+---------------------------+--------+---------------------------------+---------+---------+------------------------------------------+------+-----------------------------------------------------------+
|  1 | SIMPLE      | app_catalog_filter_values | range  | PRIMARY,param                   | param   | 8       | NULL                                     |  210 | Using where; Using index; Using temporary; Using filesort |
|  1 | SIMPLE      | app_catalog_item          | eq_ref | PRIMARY,categoryId,categoryId_2 | PRIMARY | 4       | nadommame.app_catalog_filter_values.item |    1 | Using where                                               |
|  1 | SIMPLE      | app_catalog_category      | eq_ref | PRIMARY                         | PRIMARY | 4       | nadommame.app_catalog_item.categoryId    |    1 |                                                           |
+----+-------------+---------------------------+--------+---------------------------------+---------+---------+------------------------------------------+------+-----------------------------------------------------------+

mysql> select count(*) from `app_catalog_filter_values`;
+----------+
| count(*) |
+----------+
|    71870 |
+----------+
1 row in set (0.00 sec)

 

[Boris]

WMix, подскажите , никогда не сталкивался с таким
having count(*) = 2
Что это значит?

 

[Активист]

WMix, подскажите , никогда не сталкивался с таким
having count(*) = 2
Что это значит?

http://lmgtfy.com/?q=Применение+having+в+MySQL

 

[AnrDaemon]

AnrDaemon, не люблю двойной ключик. Места чтоль жаль?

Места не жаль, жаль того, кто будет потом эту таблицу поддерживать.

 

[WMix]

AnrDaemon,

update eav set value="титановые" where id=42

или в чем проблема?

 

[AnrDaemon]

В том, что такие таблицы обычно не обновляются (i.e. твой пример теоретический), только добавляются и удаляются.
А вот добавлять в твоём случае можно "ножки стальные" и "ножки титановые" одному и тому же продукту (да, такое может быть нужно, см. ниже). Либо вводить ЕЩЁ ОДИН уникальный индекс. А когда в таблице всего один уникальный индекс, почему не сделать его PK? Зачем вводить лишние сущности?
Альтернативой можно поставить индекс (уникальный) по всем трём для ускорения DML (и исключения добавления одного и того же a+v два раза, но на самом деле такое блокируется ещё на уровне кода, если нормально). Вот СЮДА уже можно добавить id как альтернативу комплексному индексу. Но опять же не вижу большого смысла. По работе от этого дополнительного поля нет никакой пользы, одни накладные расходы на перестроение индекса при добавлении и удалении полей.

 

[WMix]

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

чем тебе мешает id? где поддержка таблички становится сложнее?

 

[AnrDaemon]

Селектить по id из этой таблицы ты не будешь НИКОГДА. Удалять - возможно.
В админке эта таблица, опять же, НИКОГДА не будет фигурировать напрямую, не говоря уже о её id.
Смысла не вижу.
Не знаю, как Вас, а меня учили, что в БД должно быть ровно столько данных, сколько необходимо для выполнения задачи. Не меньше. И ни в коем случае не больше.

 

[WMix]

Селектить по id из этой таблицы ты не будешь НИКОГДА

необходима форма по изменению значения аттрибута (хотяб для поправки ошибок грамматики)

В админке эта таблица, опять же, НИКОГДА не будет фигурировать напрямую

но из продукта можно вызвать стандартную форму изменения аттрибута

Не знаю, как Вас, а меня учили, что в БД должно быть ровно столько данных, сколько необходимо для выполнения задачи. Не меньше. И ни в коем случае не больше.

учили то правильно, но это необходимое поле. некоторые аттрибуты ссылаются к примеру на картинки через n:m табличку, опять же удобнее иметь 1 ключик.

но ты не ответил, чем мешает тебе это поле?

 

[AnrDaemon]

Не мешает. Спасибо за пояснения.