JackSхммм сначала написал своё потом наткнулся и почитал
http://www.sql.ru/forum/actualthread.aspx?tid=258519

там конечно оно правельно всё с точки зрения реляционной базы ... но для нормальной базы на нормальном сервере ... но почему то мне кажется что mysql 4.1
на шаред хостинге при сотнях тысяч записей немножко того ... уйдёт при поиске (а задача именно под такую конфигурацию)

у меня MS SQL Server. но мне тоже эта схема не подходит. нужно что-то другое придумать...

ModelRУменьшить число таблиц, но не доходя до чистого EAV можно за счет маппинга параметров в обоих измерениях - по горизонтали (полям) и по вертикали (таблицам, типам записей в таблицах).

Сегментация хранилища значений:

TVal_Number (OID, Val01 Number,...Val<N> Number)
TVal_Date (OID, Val01 Date ,...Val<N> Date )
...

Справочник параметров содержит маппинг параметров на таблицы и поля:

ParamType -> TableName
ParamID,ObjectType -> PField

Можно придумать и другие схемы маппинга.

Запросы сплошь динамические, но для Вашей задачи это не должно быть проблемой - они все равно будут формироваться вне сервера БД

что такое EAV и маппинг??

JackSесли забыть о куче таблиц и почерпнув пару идей из написанного здесь и не здесь, то что думаете о такого рода структуре:

1) категории товаров хранятся как nested sets (позабыв о доп. полях для этой структуры и прочих полях а-ля дата, активность етц упрощённо будет что то вроде ниже написанного)

cat_id cat_name cat_allow_items

cat_allow_items - флаг - возможно ли в эту категорию добавлять товары

пример категории:
...бытовая техника
.......холодильники
.......стиральные маш.
.......пылесосы

2) список товаров

item_id cat_id company_id item_name

3) таблица для связки категории товаров и возможных атрибутов таких как высота, ширина, цвет и прочее

cat_id attr_id attr_searchable

attr_searchable - флаг - будет ли доступен поиск по этому аттрибуту в этой категории

4) таблица аттрибутов товаров - список всевозможных аттрибутов

attr_id attr_type attr_name attr_unit

attr_type - тип аттрибута что то вроде - логический, список, величина - поле понадобится для того что бы:
1) знать как хранятся данные об атрибуте (вопрос про это ниже)
2) для генерации формы поиска
3) может ещё для чего то :)
attr_unit - еденица измерения для отображения: кило, сантиметр, метр, км/ч етц.

5) самая весёлая на мой взгляд таблиц(а/ы) :\ - значения атрибутов конкретного товара

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

item_attr_id item_id attr_id attr_value

item_attr_id - автоинкремент - возможно для связи описанной ниже и понадобится

то есть будет что то вроде на примемер для:
товара id = 10 (допустим холодильник - ПЛИЗ без флейма на тему "такого холодильника быть не может" - данные "с потолка")
attr_id = 4 (глубина - см)
attr_id = 5 (высота - см)
attr_id = 6 (ширина - см)
attr_id = 7 (количество камер - штук)
attr_id = 8 (объём пусть холодильной камеры - допустим куб.см)
attr_id = 9 (объём морозильной камеры - допустим куб.см)
attr_id = 10 (доступные цвета - список цветов)
attr_id = 11 (цена - у.ё.)

item_attr_id item_id attr_id attr_value1 10 4 802 10 5 2203 10 6 704 10 7 25 10 8 40006 10 9 80007 10 10 СССССС--FFFFFF--AAAAAA8 10 11 400

СССССС--FFFFFF--AAAAAA - доступные цвета - разделитель запятая или тип поля вроде "enum" или "set" - очень давно лишь раз ими пользовался не в курсе на данный момент об их слабо-сильных сторонах

а теперь назревшие вопросы:
предложите плс как лучше организовать связку "товар - его атрибуты" вместо таблицы 5)

как лучше (быстрее и легче для базы при поиске/выводе) организовать хранение attr_type списочного типа (в примере это список доступных цветов СССССС,FFFFFF,AAAAAA)
заводить ещё одну таблицу для хранения такого типа атрибутов для товара не хотелось бы ... уж больно много всяких джоинов по не маленьким таблицам ... боюсь это жестоко будет для мускла и шаред хостинга а-ля

item_attr_id attr_value7 СССССС7 FFFFFF7 AAAAAA


я думаю что всё правильно. сама накидала аналогично...
в пятой таблице предлагаю завести ещё поле id_parent (это как раз для хранения значений спискового типа...)

у меня вот такая структура 5-ой таблицы:

id - код записи
id_param - код параметра товара (атрибута)
id_part - код товара
value - значение
id_parent - ссылка на предыдущее значение из списка (для организации списка)

id_parent будет принимать целые значения. если значение id_parent = -1, то запись является самой первой в списке (или вообще единственной для других не списковых типов данных)

Ну например (см. рисунок)

уточнение:

[id_parent] - ссылка на [id] записи предыдущего значения из списка..

Аленочка тм