структура данных для хранения товаров с разным набором характеристик

[jer]

структура данных для хранения товаров с разным набором характеристик

Существует задача хранения разношерстных товаров (товаров с разным набором характеристик) в базе. Например: холодильник, телефон, телевизор, кондиционер и т.д... набор товаров может меняться.

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

Пока я представляю себе так ситуацию:
1. все товары хранить в одной таблице
2. т.к у любых товаров есть общие свойства, то их так и храним (в постоянных полях) в таблице prod (для определенности), это (id-товара, id-типа товара, id-фирмы производителя, модель, картинка, описание, цена, id-раздела каталога)
3. а все не общие поля храним в той же таблице но следующим образом: создаем n-е количество полей prod_charact1, prod_charact2, ..., prod_charactn, в которых храним все характеристики товара.
4. для идентификации товаров разных типов имеется таблица prod_charact в которой имеются поля (id-типа товара, prod_charact1, prod_charact2, ..., prod_charactn), в которых хранятся названия характеристик для каждого типа товара, если характеристика отсутствует, то поле пустое.

вот первое что пришло в голову...
Если кто-то решал подобную задачу более изящно или знает как это сделать, буду очень пирзнателен за помощь...

 

[jer]

то ли много написал, то ли непонятно задал вопрос, что-то никто не отвечает... ;(

 

[Bloody]

Можно хранить характеристики товаров в одном поле типа TEXT, разделенные знаком, например, ';'. Или в формате:
"Название_характеристики1: значение_характеристики1; Название_характеристики2: значение_характеристики2...", а потом в PHP бить на массив с помощью explode или split.

 

[RomikChef]

то ли почему-то люди не сидят на форуме целый день в субботу летом ;-)

 

[Crazy]

Структура определяется функциями.

Если тебе нужно просто хранить, то можно просто сериализовать объект со свойствами в текстовое поле.

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

Если нужно иметь возможность изредка делать такие запросы и не иметь геморроя с добавлением свойств, то сделать одну/несколько таблиц для хранения атрибутов (ключом будет сочетание ID предмета и имени атрибута).

 

[jer]

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

2 RomikChef : ты наверное прав , просто я смотрю (смотрел) что народ смотрит тему, но не не отвечает...

2 Crazy : мне нужно не просто хранить, но и работать с ними (то что я описал выше), и набор свойств может меняться, вернее могут добавляться новые типы товаров. не совсем понял что ты имел в виду, что структура определяется функциями? и про последний вариант... не совсем понятно

 

[Bloody]

Создается таблица с полями ID_товара, Имя_атрибута, значение_атрибута.
Ключом служит пара ID_товара, Имя_атрибута.

 

[jer]

Bloody, слишком громоздкая страктура получается, да и придется для всех товаров одного типа дублировать имя атрибута. мне такая структура приходила в голову...

 

[Crazy]

Автор оригинала: jer
если хранить все характеристики в одном текстовом поле через разделители, то трудно будет производить поиск по отдельным характеристикам, либо сортировать или группировать.

В таком случае ты знаешь ответ. Он дан выше.

не совсем понял что ты имел в виду, что структура определяется функциями?

Означает в точности то, что сказано. Дословно.

и про последний вариант... не совсем понятно

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

 

[jer]

Автор оригинала: Crazy

Означает в точности то, что сказано. Дословно.

блин, я тормоз... я не в том смысле понял слово функций, похоже я переутомился... =)

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

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

 

[Crazy]

Есть и другие варианты. Пример:

1. Создаем таблицу products с общими полями всех продуктов.
2. Создаем по таблице на каждый тип объекта и выносим в эти таблицы все спецические поля и ID продукта.

 

[Bloody]

А чем, собственно, не подходит третий вариант CrAZy?

 

[jer]

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

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

пока я остановился на своем варианте и на последнем варианте Crazy, хотя плодить новые таблицы при добавлении нового типа товара - ИМХО не совсем "красиво" (правильно).

 

[Serega]

Я делаю так:
1. На основе класса CDBTree сделал структуру всего каталога (все разделы/подразделы);
2. в отдельной таблице храню список всех товаров с общими полями для всех разделов/подразделов;
3. Список всех дополнительных характеристик храню в отдельной таблице, там же хранится тип характеристики;
4. Привязка определённого набора дополнительных характеристик к какому-либо разделу/подразделу хранится в отдельной таблице;
5. Есть таблица в которой хранятся все дополнительные характеристики для всех разделов/подразделов;
Итого:
5 таблиц, в которых сложно, но возможно разобраться, зато потом не будет геморроя при добавлении/удалении дополнительных характеристик для любого раздела/подраздела.

ЗЫ. Может это и топорное решение но оно работает....

 

[vad]

У меня та же проблема. Я думаю сделать структуру базы так как рекомендует Серега. Наиболее универсальный имхо способ. Только у меня ситуация еще сложнее как быть если некторые свойства одного и того же товара различны. Ну например возьмем автомоби:
у одной и той же модели может быть
1) разный объем двигателей
2) Разное потребление горючего
3) цена и т.д.

Данные нужно выводить в виде таблицы. Как это лучше сделать?

 

[jer]

а как у одного и того-же атомобиля (товара) могут быть разные:
1) разный объем двигателей
2) Разное потребление горючего
3) цена и т.д.
???

это уже разные автомобили имхо, по крайней мере модификации.

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

 

[vad]

Автор оригинала: jer
а как у одного и того-же атомобиля (товара) могут быть разные:
1) разный объем двигателей
2) Разное потребление горючего
3) цена и т.д.
???

это уже разные автомобили имхо, по крайней мере модификации.

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

 

[jer]

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

все зависит от того что тебе нужно делать с параметрами, просто выводить, либо производить поиск/сортировку по ним, одновременно по нескольким или по одной характеристике. об этом выше писал Crazy.