Как организовано описание характеристик разных товаров в интернет-магазинах

[mcfalu]

Как организовано описание характеристик разных товаров в интернет-магазинах

Вопрос такой, вот интересно каким образом организовано хранение описание характеристик разных видов товаров.
Например у аудио и видео техники основные характеристики разные, и каким образом это хранится в базе.
Как я вижу есть 2 способа:

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

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

Уважаемые знатоки, подскажите как правильно??

 

[dimagolov]

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

 

[Popoff]

я в таких случаях часто использую одно текстовое поле + serialize()

 

[dimagolov]

Popoff, а как поиск проводить в таком случае? атомарность ведь нарушается...

 

[Gas]

dimagolov
а никто не говорил о поиске, речь шла о хранении

 

[dimagolov]

Gas, как это никто не говорил о поиске? ТС писал конкретно:

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

 

[Gas]

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

 

[MiksIr]

почти офтопик: postgres+hstore+индекс=)

 

[Gas]

MiksIr
интересно, а реально работает индекс при поиске нескольких значений и сортировке?

я вот смотрю и думаю, где слышал об Олеге Бартунове, а оказывается вот прямо сейчас читаю sql.ru

 

[advocat]

если интересен сам вопрос, и есть время разобраться, могу предложить познакомится c Magento (magentocommerce.com) и ее моделью EAV
Правда EAV не узкоспециализирована на одном хранении отдельных характеристик товаров
Но для общего развития посмотреть стоит

В двух словах принцип простой, есть смотреть в разрезе простого продукта - продукт привязан к Attribute Set (по сути набор атрибутов)
При этом остальные параметры хранятся в распределенных таблицах описаных в EAV модели, правда, для каждого типа данных своя таблица

 

[MiksIr]

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

 

[Кощей]

MiksIr
А можно подоходчивее чуточку, вы предлагает е использовать другой подход ?

 

[MiksIr]

У? Еле вспомнил о чем тут вообще.
Не предлагаю, но можно. Есть тип данных для постгреса - hstore. По сути позволяет хранить хеши (ассоциативные массивы), работать с ними (объединять, пересекать, искать и т.д.)... ну и строить индекс тоже можно. Не знаю, как это по скорости с обычной таблицей, но если нужно хранить множество информации по которой поиск редок - самое оно.

 

[Кощей]

MiksIr
Что такое хеши, перловикам ясно) Спасибо за информацию. Хорошая штука сохранить хеш, в мускуле мне вот нехватает сейчас.
А этот хеш только одноуровневый можно вложить ?

-~{}~ 11.08.08 23:51:

MiksIr
Это я по форуму искал, все что можно про создание универсального уникалного супер-мега католога

 

[Anarki]

Хранить вложенные структуры в одном поле субд плохо, потому что это нарушает НФ.
Тут просто надо сесть и представить товар и атрибуты его. Понять что может быть атрибутом товара, по сути у атрибута есть название, значение и все.

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

 

[Кощей]

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

 

[Anarki]

А я хочу, чтобы программа умела варить кофе.
Реляционные базы устарели. Для бизнес логики каталог телефонных номеров может еще сгодятся.
Кощей

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

Добавляем поле parent, все, можете сажать деревья.

 

[Кощей]

Anarki
А какой тип основного поля вы предполагаете для данных ?

 

[kode]

почему нельзя сделать в три таблицы?

1 - таблица товаров
2 - таблица свойст
3 - таблица свойств товаров

те

1)
id | title | .....
0 - Сковородка

2)
id | title | values
0 - покрытие - [тефлоновое|титановое|платиновое|....]

3)
id | good_id | property_id | value
0 - 0 - 0 - 'золотое'

 

[MiksIr]

Если не нужен поиск, ничего не мешает ключу назначить сериализованную структуру. Или эмулировать вложенные структуры делая составной ключ типа key_0 key_1 etc
kode да можно, конечно, но hstore позволяет это организовать красивее. Как и связь один-ко-многим реализовывать в некоторых случаях через тип данных "массив", а не делать лишнюю таблицу.