товар с неограниченным кол-вом доп. полей

[Kirill]

товар с неограниченным кол-вом доп. полей

Сори за тупой вопрос, но все же:
Товар, у которо в зависимости от категории есть разные наборы полей (зарении известные, в зависимости от категории).
Как это лучше хранить в БД? я хочу сделать так:
таблица товаров:
id
id_category
.... стандартные поля товара (цена, название и проч.)

таблица с доп полями:
id
id_product
field_name
value

Минус в том, что в таблице с доп. св-вами могут быть и текстовая информация и числа, поля value будет только текстовым, хотя это впринципе роли не сыграет.

 

[akd]

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

 

[zerkms]

akd
ошибаешься

http://phpclub.ru/talk/showthread.php?s=&threadid=97547

 

[tashkentchi]

В своих проектах использую следующую структуру (упрощаю):

Таблица категорий товаров (subjects): id, parent_id, name, ...

Таблица товаров (goods): id, subject_id, name, ...

Таблица параметров (params): id, subject_id, name, type, ...

Таблица значений параметров (param_values): param_id, goods_id, value, ...

Поле type в таблице params имеет тип char(1) и значения:
i - целое
f - дробное
d - дата
и т.д.

Значения параметров (в таблице param_values) обрабатываются соответственно типам параметров.

Параметры наследуются. То есть, если для категории "Мониторы" имеет смысл параметр "диагональ", то считается, что он имеет смысл и для подкатегории "LCD-мониторы".

Основной геморой в этой структуре - реализация переноса подкатегории из категории_1 в категорию_2, так как на товары из подкатегории могли быть уже указаны значения параметра, заведенного на категорию_1, и который не имеет смысла для категории_2. Если при переносе убивать эти значения, то огребаешь море эмоций со стороны пользователя (который эти значения вносил). Поэтому приходится реализовывать специальный мастер переноса. А это усложняет интерфейс.

 

[dark-demon]

хех, sqlite просто создана для таких задач :-ъ там нет типизации столбцов.

 

[tashkentchi]

Вернее там нет статической типизации. Но зато есть манифестная типизация. Тип столбца - это тип записи по умолчанию.

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

 

[akd]

zerkms, почитал, интересно. спасибо.

-~{}~ 02.04.07 10:11:

zerkms, ша вернулся еще.
я правильно понял по структуре, что в catalogue_catalogue_data присутствует избыточность именно для того, чтобы предусмотреть "все" типы данных?

 

[zerkms]

akd
да, а это "предусмотрение" нужно для оптимизации (см. расстановки индексов)

 

[akd]

zerkms, угук, это я поняло.

как будут результаты по нагрузкам, поделишься?

 

[Alexandre]

если нет поиска по доп полям, а БД Мускуль от 5й версии и выше , то рекомендую использовать XML.

Иначе, как уже говорили:

связка таблиц object -> property

где property - таблица неограниченных свойств товара.

Однако для Админки еще необходимо сделать привязки категории и свойства, т.е. чтоб вываливались в данной категории товаров не все свойства, а только присущие этой категории товаров. Кстати эту часть я сделал с использованием XML.

А вот XML поле property пришлось переделать в таблицу.