Структура таблиц для динамического меню. Подскажите идею структуры.

mar_a · 24 Сен 2010

Структура таблиц для динамического меню. Подскажите идею структуры.

Необходимо подать идею как оптимально построить таблицу для динамического построения меню которое будет меняться в зависимости от заданных характеристик товаров. По умолчанию строится таблица всех (заранее заданных) возможных параметров моделей (с группировкой по типу свойства).
Например для ноутбуков:
Частота процесора
1000[20], 1200[50] ,1500[30] ...
HDD
120[10], 250[90], 300[45] ...
RAM (1G[34], 2G[190] ...
и т.д. т.п.
При выборе скажем параметра для частоты процессора 1200
должны оставаться остальные параметры этого меню но со всеми параметрами удовлетворяющ. условию частоты процессора -=1200
Скажем так остаться из примера должны:
Частота процесора
1000[+20], 1200[50] ,1500[+30] ...
HDD
120[5], 250[40], 300[5] ...
RAM
1G[10], 2G[40] ...

Т.е. как видно остальные свойства выведены в области разреза частоты процессора.

Что дано...:
И так есть таблица товаров:
Tovar c полями:
id, name , note и т.д. (ключ на ID)

Таблица Property_value где храняться названия свойств товаров
id_property (ключ) , Name (название свойства), position (позиция для очередности вывода)

Таблица Property c полями
id_tovar , id_property , value
Где id_tovar - привязка к таблице товаровTovar
id_property - привязка к таблице свойств товараProperty_value
value - само свойство товара.

Теперь суть вопроса:
Необходимо помочь разобратся с созданием (структуры) сводн(ой)(ых) таблиц(ы)
для разумного (оптимального) быстрого построения такого меню.
Напрашивается некий аналог OLAP куба.
Нет конечно можно было создать SQL запросы которые без дополнительных таблиц создавали - бы требуемую картинку меню. Но время выполнения такой серии запросов не устраивает.
Прошу адекватной помощи, может кто сталкивался с подобного рода задачами.

prolis · 24 Сен 2010

Re: Структура таблиц для динамического меню. Подскажите идею структуры.

А в чем подвох автоматического пересоздания на этой основе нормальных таблиц свойств групп товаров (id_tovar, property_1, property_2...). Не стали сразу делать, генерите сейчас.

mar_a · 24 Сен 2010

prolis
Т.е. Вы предлагаете создать упрощенную таблицу в которой в каждый товар однозначно привязан к только ОДНОМУ свойству одного вида?
Меня это также неустраивает...
Возьмем пример указанный выше надо бы добавить что НОУТБУКИ имеют свойства (по которому я также буду сортировать как товары так и динамическое меню)
Интерфейсы
Где одному товару может быть одновременно присвоенно несколько свойств LAN и WiMax и WiFi
Cледуя предложенной Вами структуре у меня добавиться избыточные данные и весьма существенные.

Често говоря не то что я хотел-бы видеть и ожидал...

-~{}~ 24.09.10 12:47:

Автор оригинала: prolis
Не стали сразу делать, генерите сейчас.

На основании имеющихся данных такую таблицу не составит труда сгенерировать но пока еще рано...

prolis · 24 Сен 2010

ну почему приявязан к одному свойству, ко всем, которыми обладают товары данной группы.
А насчет нескольких однотипных свойств (LAN/WiMax/WiFi) - у вас их и сейчас нет в вашей структуре, они там проходят под отдельными свойствами продукта.

mar_a · 24 Сен 2010

Автор оригинала: prolis
А насчет нескольких однотипных свойств (LAN/WiMax/WiFi) - у вас их и сейчас нет в вашей структуре.

Как нет:
в таблице
Property c полями
id_tovar , id_property , value

вот тут НЕТ уникальности на id_tovar!
Нет уникальности и на id_tovar + id_property !
Т.е.

11,7,WiMax
11,7,WiFi
11,7,LAN
11,7,Bluetooth
(Где:
11- конкретная модель ноута Acer,
7 Тип свойства=Интерфейсы)

Как это будет выглядеть в ВАМИ предложенной структуре:
11, 1200, 250, 2G , .... , WiMax, ...
11, 1200, 250, 2G , .... , WiFi, ...
11, 1200, 250, 2G , .... , LAN, ...
11, 1200, 250, 2G , .... , Bluetooth, ...

Это если я ВАС правильно понял...
А на секундочку , ведь Интерфейсы - не единственный тип свойства которое у меня может быть с однотипными свойствами. Есть еще и другие типы свойств.

dimagolov · 24 Сен 2010

google://EAV

mar_a · 24 Сен 2010

dimagolov
Entity-attribute-value model ?
А можно по подробнее...
Заинтересовало....

prolis · 24 Сен 2010

то что вы назвали интерфейсом является собственными свойствами "наличие WiMax", "наличие LAN" и "наличие Bluetooth", т.е. отдельные столбцы в сводной таблице товара данного класса.
Единственное, что я могу представить в виде списка значений одного поля, это список поддерживаемых протоколов (Wi-Fi 802.11n, Wi-Fi 802.11g, Wi-Fi 802.11b)

mar_a · 24 Сен 2010

prolis
То ли Вы меня не понимаете , то ли Я ВАС.
Можно продемонстрировать на конкретном примере в виде таблички (или нескольких). Так что-б я явно увидел где поле заканчивается и начинается новое.

dimagolov · 24 Сен 2010

mar_a, гугл дал мало ссылок?

mar_a · 24 Сен 2010

Да спасибо за идею , по крайней мере надо будет конкретизировать по EAV уже.
Пока тема для размышлений найдена, осталось только собрать и переосмыслить. Всем спасибо.

-~{}~ 29.09.10 10:55:

Итак что вышло благодаря советам (если правильно понял идею).
Пришлось создать дополлнительные таблицы:
1)Value
val_id
val_name

2)Tab_stat - (таблица связывающая товары и их свойства в нормальном виде... в каждое поле под номером свойства попадает значение val_id привязывающие каждые значения свойства к категории свойств. К стати в эту таблицу я вынес только те категории свойств которые будут содержать только одно значение , год, вид и т.п. характеристики которые однозначно привязаны только к одному товару.)
id_tovar
prop_1
prop_2
prop_5
prop_10
....

3)Tab_3 (таблица содержащая все возможные варианты привязки одного товара к одной категории свойств которая может одновременно быть присвоена к нескольким конкретным значениям , например ИНТЕРФЕЙСЫ , могут быть и (или) (LAN/WiMax/WiFi) )
id_tovar
val_7
val_8
val_9
val_10
.....

Ну еще подобная Tab_3 таблицы: Tab_4, Tab_6 , Tab_7 ...
которые аналогично могут содержать несколько значений свойств привязанных к одному товару (разумеется других).
В этих таблицах будут находится значения связывающие с таблицей Value.

4)Разумеется добавилось еще одно поле в Таблице Property
id_tab cвязывающее категорию свойства с той таблицей где существуют привязки к различным свойствам товаров.

Теперь вопросы которые возникли при окончательном осмотре такой структуры БД:
Не универсальность (а если добавиться параметр или новое значение свойства связанный(ое) с товаром один товар к множеству свойств - то:
- Необходимо будет добавлять таблицу , (и)или добавлять поле в уже существующие таблицы.

Таблицы не оптимальны и могут содержать пустые поля (пусть даже и не все).

Что меня и настораживает , прошу помощи у специалистов , можно ли глубже оптимизировать такую структуру БД. Правильно ли понята идея?
(Просто с подобной задачей сталкиваюсь впервые, поэтому прошу помощи и критики в свой адрес ).

prolis · 29 Сен 2010

Так определеись уже, что надо: EAV или фиксированный набор свойств объектов?

mar_a · 29 Сен 2010

Честно сказать в сомнениях...
Если-бы определился то вопросов не задавал...
Есть свои плюсы и минусы в обоих технологиях.
Как мне показалось то я создал структуру на основе прочитанного именно по EAV. (Или опять ошибаюсь).
Cущность - атрибут - значение
Вдохновило :http://habrahabr.ru/blogs/sql/45935/#habracut
задача описанная там вполне похожа на мою,
и как описал сам автор цитирую:
(Сразу скажу, что не знаю как эта задача решается эталонно, но решить ее нужно было быстро и потому я подумав сделал то решение о котором буду рассказывать.)
Собственно и смущает эта фраза... (или настораживает).
Исходя из последнего и возник вопрос , а как кто решает такого рода задачи (как правильнее ?). Задачка то тривиальна...

PS: EAV - читал разные мнения и самый яркий из них это на Хабрахабре в записках программиста 10 вещей которые сотворил я и очень зря - среди этих 10 вещей есть и негатив по EAV.

Или вот еще: EAV модель
СХЕМА
В интернете про нее написано много чего. Но основная идея, подверженная на практике использовать ее только в том случае когда необходимы сущности задаваемые пользователем. Это настолько редкий класс проектов, что о них даже не стоит говорить.
В любом другом случае мы получаем неудобочитаемую, медленно работающую структуру. Без каких-либо плюсов.
взято из http://habrahabr.ru/blogs/personal/36735/
Сущность в моем случае пользователь не должен создавать...
так что не обессудьте...

Хочу лишний раз удостовериться что на правильном пути.(или ложном).

prolis · 29 Сен 2010

Автор оригинала: mar_a
Сущность в моем случае пользователь не должен создавать...

Тогда 2 таблицы. Одна со значениями конкретных свойств товара, вторая с привязкой нескольких значений одного свойства к товару.

mar_a · 29 Сен 2010

У меня изначально так и было(есть).
2 таблицы , но !
Необходимо построить таблицу для динамического построения меню которое будет меняться в зависимости от заданных характеристик товаров. (см. выше в первом посте).
И если выборку делать серией запросов из этих 2-х таблиц то скорость выполнения запроса меня не устраивает (запрос получается слишком тяжелый).
Поэтому и решил задать вопрос именно для построения динамического меню (см. выше в первом посте).

А как Вы (ты) поступил если-бы была подобная задача?

dimagolov · 29 Сен 2010

запрос получается слишком тяжелый

и сколько у тебя свойств и их значений? явно не миллионы ведь. читай про индексы и оптимизацию запросов, про explain

prolis · 29 Сен 2010

Автор оригинала: mar_a
И если выборку делать серией запросов из этих 2-х таблиц то скорость выполнения запроса меня не устраивает (запрос получается слишком тяжелый).

[sql]select count(*) from tovar where field = 1200[/sql]
[sql]select count(distinct t.id_tovar) from tovar t,property p where t.id_tovar=p.id_tovar and p.value='802.11n'[/sql]
- вот два вида запроса, которые могут быть, где им тут тормозить непонятно.

mar_a · 29 Сен 2010

О да тут им негде тормозить...

Вы продемонстрировали связь между 2 таблицами
и выбрали все товары которые удовлетворяют свойству =802.11n
Ок , в результате такого запроса их 50 штук (предположим) - так вот из этих 50шт мне необходимо вывести все свойства с подсчетом .
Ну для примера : с процем 1200МГц - 3шт
1500МГц - 7, 2000МГц -30 2200МГц-10 (из 50шт)
Плюс ко всему другие свойства :
HDD
120[5], 250[40], 300[5] ...
RAM
1G[10], 2G[40] ...

Так вот для этого еще необходимо выполнить запрос на отбор всех параметров которые связаны с отобранными товарами (ноутами).

Помоему Вы меня не поняли , я об этом писал в первом сообщении...

prolis · 30 Сен 2010

[sql]
SELECT property_1, count(DISTINCT t.id_tovar )
FROM tovar t, property p
WHERE t.id_tovar = p.id_tovar AND p.value = '802.11n'
group by property_1
[/sql]

mar_a · 30 Сен 2010

Автор оригинала: prolis
Тогда 2 таблицы. Одна со значениями конкретных свойств товара, вторая с привязкой нескольких значений одного свойства к товару.

Хорошо 2 таблицы.

1-я) property_value
prop_id - ключ
prop_name - значение конкретного свойства товара

2-я)Property-2-Tovar таблица связывающая товары с их свойствами
prop_id
tovar_id

3-я)(Она-же нулевая это собственно сами товары)Tovar c полями:
tovar_id - ключ
name
note и т.д.

В предложенном ВАМИ запросе связь между 1-2 таблицами (ну это не столь важно).
Вы по прежнему обработали и подсчитали мне свойство только по критерию '802.11n'
Соответственно есть привязка к товарам и подбираются только критерий свойства под названием '802.11n'
причем остальные как вы догадались не удовлетворяют заданному условию, т.к. они естественно не равны значению '802.11n'.

Как мне кажется необходимо выполнить в начеле запрос :

PHP:

Select p2v.tovar_id  AS PROPERTIES_1
FROM Property-2-Tovar as p2t , property_value as p 
Where p.tovar_id=p2t.tovar_id
AND p.value='802.11n'

Это первая часть запроса определяющая перечень товаров которые удовлетворяют данному требованию
т.е. ВСЕ товары у которых есть 802.11n.
Теперь необходимо дать запрос на то , а какие свойства у этих отобранных товаров есть помимо 802.11n:

PHP:

Select p.value, Count(Dictinct p.tovar_id) 
FROM Property-2-Tovar as p2t , property_value as p , PROPERTIES_1 as p2
Where p2.tovar_id=p2t.tovar_id AND p2t.tovar_id=p.tovar_id
Group By p2v.prop_id

Где-то так...
В результате мы должны получить все свойства значений (с подсчетом) которые удовлетворяют данному условию 802.11n.

Для простоты понимания можно посмотреть как это все выглядит на примере тут http://hotline.ua/gd/12/911
Обратите внимание на левое меню в котором включаются фильтры и ведется подсчет по различным свойствам (параметрам).

PS Может действительно я не совсем точно описал суть , может действительно проще было задать вопрос в таком контексте : ХОЧУ ОРГАНИЗОВАТЬ ФИЛЬТРЫ КАК ТУТ http://hotline.ua/gd/12/911
Может так будет понятнее...

Структура таблиц для динамического меню. Подскажите идею структуры.

Новичок

Новичок

Новичок

Новичок

Новичок

Новичок

Новичок

Новичок

Новичок

Новичок

Новичок

Новичок

Новичок

Новичок

Новичок

Новичок

Новичок

Новичок

Новичок

Новичок