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

[prolis]

Да что же такое, никак вы не поймете, есть одна (две) таблицы (здесь и далее одна, так как в указанном вами сайте тоже не используются несколько значений для одного свойства):
Таблица Товары:
1 модель
2 производитель
3 процессор
4 цена

Далее строим ваше меню по производителям:
select производитель, count(*) from tovar group by производитель
Аналогично по всем другим параметрам достраиваем меню.
Пользователь выбирает Acer, тогда повторям тоже самое, но добавля "where производитель='Acer'"

 

[mar_a]

В каждом отдельном случае если выбираем по одному свойству , вроде-бы задача и действительно проста.

В спокойном состоянии я рассматриваю как вы мне и предлагаете:
Делаем выборку по производителю , выбираем только Acer .

Вопрос сколько у этих отобранный моделей есть свойств(параметров):

Видеоадаптер, производитель
ATI (111)
NVidia (35)
Intel (59)
Видеоадаптер, чипсет
Intel GMA (53)
Intel HD Graphics (6)
ATI Radeon HD 2xxx, 3xxx (11)
ATI Radeon HD 4xxx, 51xx, 54xx (68)

И т.д.
Причем если детальнее присмотреться то некие свойства(параметры) просто выпали из выборки...

Если мы имеем структуру предложенную ВАМИ.
То мы будем использовать фиксированное меню (свойств фильтров)
Т.е. если пользователь выбрал Acer то
остальные свойства меню не поменяются , как были
скажем свойство HDMI выходы так они и останутся , а на самом деле во всех отобранных моделях нет ни одной у которой этот выход HDMI есть.

Как я (ВЫ, МЫ) можем узнать согласно предложенной ВАМИ структуре :
При выборе одного из свойства (конкретного значения) сколько остальных свойств других характеристик останутся.
Т.е. пример: Выбрали Acer ,
вопрос сколько моделей фирмы Acer имеют
Разрешение экрана
1024x600 (?)
1280x800 (1280x720) (?)
1366x768 (?)
1440x900 (?)
Видеоадаптер, производитель
ATI (?)
NVidia (?)
Intel (?)
Тактовая частота, GHz
менее 1,5 (?)
1,5-1,99 (?)
2,0-2,25 (?)
2,26-2,5 (?)
Ну и т.д.

-~{}~ 30.09.10 14:50:

Автор оригинала: prolis
Таблица Товары:
1 модель
2 производитель
3 процессор
4 цена

Стоп только сейчас увидел где между нами разногласие получилось, Вы в таблицу Товар
понимаете как свойства товара?
А у меня это таблица Property_value (см в самом первом посте)
Потом есть еще связь через таблицу соответствий Property к товарам Tovar.

 

[prolis]

1. в середине первой страницы мы(вы) решили что не стоит заигрывать с EAV, поэтому одной простой таблицы хватит для 99% свойств.
2. "сколько моделей фирмы Acer имеют Разрешение экрана" ну писал же уже:
[sql]
select resolutin,count(*) from tovar where vendor='Acer' group by resolution
[/sql]
видеоадаптеры, аналогично:
[sql]
select video,count(*) from tovar where vendor='Acer' group by video
[/sql]
и так для всех ключевых параметров

 

[mar_a]

Немного отвлекся , запросы действительно простые.
Теперь Вас не смутит что для каждого свойства прийдется делать по одному SQL запросу.
Скажем для формирования простенькой менюшки прийдется как минимум N раз пустить запросы пусть даже простые.
В моем случае это количество будет привышать 10, и это при том что формируется только одна менюшка со свойствами.

Скажем так есть к такому методу тоже претензии , но тем не менее попробую на реальной БД отпишусь.

 

[prolis]

Можно и одним запросом, но к агрегату, структура которого по столбцам и строкам соответсвует ВСЕМ возможным значениям свойств, например:
A B C D
A 5 4 1 0
B 0 5 3 2
C 1 2 5 2
D 0 0 5 5
Где в столбцах ABCD указаны количество товаров с данным свойством, соотвствующие строкам свойств ABCD. Привожу чисто из теоретических соображений, но если сильно прижмет - можно и реализовать. Единственное ограничение - количество столбцов не превысит 4096. Хотя, если в меню 20 типов свойств, каждый из которых содержит по 10 уникальных значений, то потребуется "всего" 200 столбцов.

 

[mar_a]

Ок попробую варианты , если что непойму то отпишусь...
Заранее спасибо за не зря (для меня) потраченное время...