проектирование БД интернет-магазина

← →
Handle (2012-05-30 15:24) [0]

Делаю БД интернет-магазина. Помимо основных атрибутов товаров (например: артикул, цена, ...), нужно хранить создаваемые пользователем атрибуты (например: объем памяти, тип экрана, ...). Помогите определиться со структурой таблиц для хранения атрибутов.

Пока что сделал:

Таблицы:

products (id, ...)
product_categories (id, parent_id, ...)
product_categories_and_products (id, product_category_id, product_id)

Связи:

products 1 --- * categories_and_products
product_categories 1 --- * categories_and_products

← →
Handle (2012-05-30 15:42) [1]

С чем связывать атрибуты: с товарами или категориями?

← →
картман © (2012-05-30 15:51) [2]

а у товаров одной категории могут быть разные наборы атрибутов?

← →
Jeer © (2012-05-30 18:19) [3]

> Помогите определиться со структурой таблиц для хранения
> атрибутов.

Бесполезно.
Для каждого вида товара - свой описатель.
Не представляю , как в одной таблице (реляционной) хранить данные о HDD и фотокамере. Тут нужна объектно-иерархическая БД.

← →
картман © (2012-05-30 18:58) [4]

> Не представляю , как в одной таблице (реляционной) хранить
> данные о HDD и фотокамере.

table_tovar_to_attribute

← →
Кщд (2012-05-31 07:17) [5]

>картман © (30.05.12 18:58) [4]
>table_tovar_to_attribute
кроме того, что за такие именования таблиц надо карать, надо, как минимум, вводить ещё и сущность "тип атрибута"(например, "объем HDD", "диагональ монитора" и пр.) и "категорию атрибута"(например, "жесткий диск", "монитор" и др.). ми-ни-мум.
т.е. приходим к EAV и прочему аду при большом кол-ве товаров.
правильно было сказано в "Jeer © (30.05.12 18:19) [3]".

>Handle (30.05.12 15:24)
дорогой автор, что в вашей сумбурной модели означает "category"? атрибуты, создаваемые пользователем?

← →
Anatoly Podgoretsky © (2012-05-31 07:28) [6]

> Кщд (31.05.2012 07:17:05) [5]

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

← →
brother © (2012-05-31 07:30) [7]

> хранить данные о HDD и фотокамере.

по полю наименование... создаем поля spec1, spec2 итп... в них, в зависимости от наименования записываем необходимую информацию...

← →
Кщд (2012-05-31 07:40) [8]

>Anatoly Podgoretsky © (31.05.12 07:28) [6]
под типом атрибута подразумевал не типизацию(number, date, varchar и пр.), а именно справочник:
>"тип атрибута"(например, "объем HDD", "диагональ монитора" и пр.)

← →
Anatoly Podgoretsky © (2012-05-31 08:40) [9]

> Кщд (31.05.2012 07:40:08) [8]

Я тоже самое имел ввиду.
Как обычно это выглядит в прайсах

64/512/Черный/450 вт

Редкость
64 Кеш L1/512 Кеш L2/Корпус черный/БП 450 вт

И поиск БП 450 вт
Найдет в обеих случаях

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

← →
Anatoly Podgoretsky © (2012-05-31 08:43) [10]

> brother (31.05.2012 07:30:07) [7]

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

← →
картман © (2012-05-31 11:52) [11]

> кроме того, что за такие именования таблиц надо карать,

а это не было наименованием таблицы, то был ответ

> т.е. приходим к EAV и прочему аду при большом кол-ве товаров.

ад-то почему? Да и начхать к какой там аббревиатуре приходим - через пару лет маркетологи придумают новую

← →
Кщд (2012-05-31 12:07) [12]

>картман © (31.05.12 11:52) [11]
>ад-то почему? Да и начхать к какой там аббревиатуре приходим - через >пару лет маркетологи придумают новую
это технический термин(аббревиатура)
а ад потому, что для того, чтобы достать один(!) атрибут(например, "объем HDD"), необходимо объединить три таблицы.
при большом кол-ве сущностей и атрибутов у них, производительность стремительно падает.

← →
DVM © (2012-05-31 12:16) [13]

> Anatoly Podgoretsky © (31.05.12 07:28) [6]
> > Кщд (31.05.2012 07:17:05) [5]
>
> Учитывая, что это Интернет магазин, то тип не нужен, атрибуты
> можно задавать
> в произвольной форме, в текстовом виде. Специфика поиска
> в Интернет
> магазинах. Но вот справочник атрибутов не помешает

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

← →
DVM © (2012-05-31 12:22) [14]

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

Да прямо так уж и падает. Аттрибутов не миллионы, как правило немного.

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

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

Товары имеет тип соответственно.

← →
DVM © (2012-05-31 12:24) [15]

> DVM © (31.05.12 12:16) [13]

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

← →
Anatoly Podgoretsky © (2012-05-31 12:27) [16]

> DVM (31.05.2012 12:16:13) [13]

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

← →
Кщд (2012-05-31 13:01) [17]

>DVM © (31.05.12 12:22) [14]
>Да прямо так уж и падает. Аттрибутов не миллионы, как правило немного.
если Вы пишите конкретно про интернет-магазины, то, вероятно, правы
а вообще, в EAV нередки случаи, когда объектов миллионы и у каждого по несколько десятков атрибутов
впрочем, Вам это известно

> Anatoly Podgoretsky © (31.05.12 12:27) [16]

> Ты видил когда нибудь Интернет магазин, норма когда нет
> никаких атрибутов.

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

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

Можно поподробнее, в чем тут проблема? Если есть индекс по entity, то все атрибуты легко вытаскиваются одним селектом (select * from eav where e=?). Разве большая разница по скорости между получением 10 строк из одной таблицы или 10 колонок из одной строки, опять же из одной таблицы?

← →
Кщд (2012-05-31 13:23) [20]

>Компромисс © (31.05.12 13:10) [19]

> Разве большая разница по скорости между получением 10 строк
> из одной таблицы или 10 колонок из одной строки, опять же
> из одной таблицы?

1. я ничего не говорил про одну таблицу;
2. разница есть;
3. что Вы спросили - увы - не понял;
4. жаль.

← →
Кщд (2012-05-31 13:46) [21]

возможно, был неверно понят некоторыми участниками дискуссии.
объяснюсь.
о чем говорил: google + define:eav.
чем плохо: google + EAV hell.

Почему бы какой-нибудь CouchDB не взять или аналог?

Кщд (31.05.12 13:46) [21]

Я действительно неверно понял.

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

То есть вместо

select
s1.objectid SID
,s1.paramvalue GSID
,s2.paramvalue FIRSTNAME
...
from
(Select objectid,paramvalue from TMP_PARM where paramname="GSID" ) s1,
(Select objectid,paramvalue from TMP_PARM where paramname="FIRSTNAME" ) s2,
...
WHERE object_id=?
s1.objectid = s2.objectid
and s1.objectid= s3.objectid

я бы тупо делал

Select objectid,paramvalue from TMP_PARM where object_id=?

Если есть "особые" атрибуты, их не стоит хранить в EAV ИМХО.

проектирование БД интернет-магазина Найти похожие ветки