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

С.

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

С.

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

Boris

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

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

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

WMix

герр M:)ller
Партнер клуба
Код:
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 правильно говорит, используйте 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

герр M:)ller
Партнер клуба
AnrDaemon,
PHP:
update eav set value="титановые" where id=42
или в чем проблема?
 

AnrDaemon

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

WMix

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

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

AnrDaemon

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

WMix

герр M:)ller
Партнер клуба
Селектить по id из этой таблицы ты не будешь НИКОГДА
необходима форма по изменению значения аттрибута (хотяб для поправки ошибок грамматики)
В админке эта таблица, опять же, НИКОГДА не будет фигурировать напрямую
но из продукта можно вызвать стандартную форму изменения аттрибута
Не знаю, как Вас, а меня учили, что в БД должно быть ровно столько данных, сколько необходимо для выполнения задачи. Не меньше. И ни в коем случае не больше.
учили то правильно, но это необходимое поле. некоторые аттрибуты ссылаются к примеру на картинки через n:m табличку, опять же удобнее иметь 1 ключик.

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