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

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

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

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

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


я думал о таком способе хранения списка,
с той лишь разницей что parent_id будет:
-1 не список
-2 список
>0 ссылка на автоинкремент ID товара у которого parent_id = -2

что то на подобии такой таблицы:

item_attr_id item_id attr_id attr_value item_attr_parent1 10 4 80 -12 10 5 220 -13 10 6 70 -14 10 7 2 -15 10 8 4000 -16 10 9 8000 -1 7 10 10 -2 8 10 10 СССССС 7 9 10 10 FFFFFF 7 10 10 10 AAAAAA 711 10 11 400 -1
но я отказался от такого подхода (хоть и не окончательно)
просто в этом случае и так очень большая таблица превращается просто в огромную, а ведь именно она будет наиболее нагруженной ...

а в чём смысл ссылки parent_id на предыдущую запись (у вас) а не на родителя (у меня) ? что то больно сложно будет выбирать/искать при таком подходе ...

если речь идёт о приоритетности вывода/поиска данных атрибутов товара то для этого достаточно и автоинкремента ...

по этому и спросил только о двух вариантах
1) отдельная таблица для списковых значений
2) а) или же специальный тип поля
б) спец формат хранения данных

1) - при поиске даёт гарантию совпадения
2.а) - ничего не могу сказать по этому поводу (а что вы можете сказать? как оно будет использовано при поиске ?)
2.б) - думал использовать LIKE для простоты не нагружая при распарске - гарантии совпадения нет но вероятность высока

что легче для базы:
1) две таблицы допустим с миллионом записей в одной и 10 миллионами в другой (речь о таблицах 2) список товаров и 5) значения атрибутов конкретного товара )
2) 1,000 таблиц в каждой по 1,000 записей (но каждая из этих таблиц будет иметь порядка 10-15 полей)

решил ещё раз спросить об этом... понимаю что 2) это извращение ещё то ... но что то меня пугают джоины/подзапросы по нездорово огромным таблицам в случае 1) нагрузка будет мне кажется жуть какая даже с учётом индексов и ограничений на выборку

Cat2Ну что ж. Если Вы считаете, что пятая таблица нужна, то мне остается только отойти в сторону. Если Вы хелаете набивать шишки самостоятельно - Бог Вам в помощь!

Вы хотели, что бы Вас похвалили, какой Вы умный и придумали супер-пупер? Так нет. Ваша задача настолько тривиальна, что даже непонятно, какие могут быть проблемы. А ваше решение - попытка почесать правое ухо лыжей, зажатой в левой руке.

===========
Не надо пугаться джоинов. При правильных индексах все простые выборки будет работать на ура.

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

а вместо ёрничества лучше бы привели конкретный пример структуры совмещённых 3) и 5) таблиц ибо я ума не приложу как это ... поля через запятую вроде как не трудно написать, мышкой выделить и ЦСВ нажать ....

так же рад что моя задача столь тривиальна для Вас что вы готовы посмотрев на все мои "старания" сходу предложить свой единственно верный вариант ? с радостью приму вашу структуру столь тривиальной базы ... у вас и дамп надеюсь завалялся что бы я неуч посмотрел да уму разуму набрался ? ну что поделать не всем быть такими умными как Вы ...

очень надеюсь что Вы не отступитесь в сторону и снизайдёте своей благодатью на мою лыжу и направите её верным путём яко товарищ Ленин к моему правому уху...

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

ModelRСловарь, таблица для связки категории товаров и возможных атрибутов
cat_id attr_id attr_searchable attrFieldХолодильник 4 (глубина ) Yes Value1Холодильник 5 (высота) Yes Value2Холодильник 6 (ширина)No Value3Холодильник 7 (количество камер )Yes Value4Холодильник 10 (доступные цвета) Yes _List...

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


Скалярные значения
item_id Value1Value2 Value3Value4...10 80 220 70 2...
Списковые
item_id attr_id attr_value1010 СССССС1010 FFFFFF1010 AAAAAA

Коль для одной категории число параметров меньше максимального числа полей в таблице СУБД то хватит одной таблицы значений, иначе или несколько таблиц или несколько типов записей.
Реально применяется, правда для MS SQL, Oracle.

Так проще? :)

гораздо проще :) ток вот вопросы есть ...
предпологается что будет уйма полей в таблице "Скалярные значения" и данная таблица будет общей для всех продуктов ?
то есть предположим у меня наберётся 500 всевозможных не списковых атрибутов товаров.
как я понял у таблицы "Скалярные значения" будет 500 полей ? :\ данная таблица будет общей для всех товаров и в некоторых полях для некоторых товаров будет стоять значение а в некоторых а-ля ничего ?
если я верно понял что думается мне что вариант с 1000 таблиц будет попроще да и пожалуй поровнее, разве нет ? :\

LSV
Тем более, что в принципе возможно(хотя нежелательно) нахождение товара одновременно в нескольких группах. Пример: Окорочка могут быть и в группе "Курятина" и в группе "Сырьё для производства". Иногда это может быть удобно.

ну "Сырьё для производства" это очень злая категория :) в неё можно впихнуть всё дерево категорий по второму разу и уйму товаров ...

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

изначальную таблицу 2) список товаров

item_id cat_id company_id item_name

разобьём на две таблицы:
первая:
2.1.а) список товаров (без привязки к категории)

item_id company_id item_name

2.1.б) это как вариант оставить упоминание о категории как об основной категории и добавить новое поле

item_id cat_id company_id item_name cat_id_inc

cat_id_inc - новое логическое поле 0/1 - находится ли данный товар в других категориях и в зависимости от него уже можно организовать возможность "товар -> несколько категорий"

вторая:
2.2) список товар-категория

item_id cat_id

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

вариант 2.1.б) с дополнительным полем + вторая опциональная таблица мне кажется достаточно гибким, что скажете ?

ModelR
Два случая встречались.
Для поиска.
Холодильник автомобильный - хочется, чтобы человек мог его найти (имеется ввиду найти навигацией по категориям) и от корня Оборудование для автомобилей и от Бытовая техника. На набор свойств это никак не влияет.


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

ModelR

Более интересный случай - множественное наследование свойств, повторное использование наборов свойств.
Это уже для администратора системы, хотя можно использовать и для форматирования отображения.
Например категории
ТВ камера - набор свойств1.
Компьютер - набор свойств2.
Ноутбук с ТВ камерой наследует оба эти набора свойств, Мобильник с ТВ камерой наследует набор свойств1.



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

(ноутбук с камерой)
promo_id, company_id, item_id
4, 10, 5 (NOTEBOOK)
4, 10, 8 (CAMERA)

не думаю что такие варианты будут часто востребованными, но как опционал можно добавить ...

нужно будет к этой возможности писать не хилый контроллер что бы товары включались сюда в зависимости от парент категории и не получалось "курица + 1ГБ ДДР памяти в подарок"
возможно создать для контроллера таблицу уровней допустимой вложенности категорий для создания комбинированного товара
+ контроллер для управления отображением в листинге (в начало, конец списка такие товары, либо же каждый десятый на пример)

но это мне кажется уже лирика ... придумать можно много :)

ModelR
те же холодильники , но сгруппированные по объему камеры.


это вариант поиска в категории холодильники по объёму морозильной камеры

ModelR
Наиболее популярные запросы также можно категоризировать в некое дерево.


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

первое что пришло в голову:
завести спец табличку с несколькими полями ...
при поисковом запросе генерить ХЭШ и писать его в табличку (если есть - увеличить счётчик + поле с названием директории со сгенеренным темплэйтом + дата последнего обновления)

в конце каждой на пример недели для наиболее популярных (методика выбора - какая кому нравится) генерить директорию с готовыми страницами результатов поиска и далее при навигации по ним уже базу не трогать вообще :)

в зависимости от даты или на пример каунтера кратного 100 перегенеривать эти страницы (крон скрипт) ... в общем это уже больше программинг и на прямую с базами не связано но спасибо за наталкивание на идею :)

возможно на пример идея с разгрузкой базы и не нова для некоторых товарищей ;) но моё дело поделиться тем что в голову по ходу пришло, кому то может и пригодится ... я ведь всётаки программер в большей мере а не спец по проэктированию баз и мыслю больше на уровне "разгрузить ресурсы" а не "корректная структура" :) - плиз без особой критики и флейма тем более что это был всего лишь "сырец", а то чую я что найдутся товарищи желающие увести в сторону разговор от основной задачи - БАЗА ...