powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Посоветуйте схему для товаров с различными категориями и параметрами
11 сообщений из 11, страница 1 из 1
Посоветуйте схему для товаров с различными категориями и параметрами
    #38889544
boroff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Есть выгрузка товаров в XML формате. В ней товары совершенно разных категорий - одежда, обувь, аксессуары. Вполне возможно, что так же будут добавлены и другие категории товаров, как например мобильные телефоны, телевизоры и тому подобное. Вот примерно то что я придумал для структуры базы (будет использоваться MySQL ):

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
-- -----------------------------------------------------
-- Schema mydb
-- -----------------------------------------------------
CREATE SCHEMA IF NOT EXISTS `mydb` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci ;
USE `mydb` ;

-- -----------------------------------------------------
-- Table `mydb`.`product_available_parameters`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`product_available_parameters` (
  `id` INT NOT NULL,
  `name` VARCHAR(255) NULL,
  PRIMARY KEY (`id`),
  UNIQUE INDEX `name` (`name` ASC))
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`product_parameters`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`product_parameters` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `product_id` INT NULL,
  `product_available_parameters_id` INT NOT NULL,
  `parameter_value` VARCHAR(255) NULL,
  PRIMARY KEY (`id`, `product_available_parameters_id`),
  INDEX `fk_product_parameters_product_available_parameters1_idx` (`product_available_parameters_id` ASC),
  INDEX `parameter_value` (`parameter_value` ASC),
  CONSTRAINT `fk_product_parameters_product_available_parameters1`
    FOREIGN KEY (`product_available_parameters_id`)
    REFERENCES `mydb`.`product_available_parameters` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`category`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`category` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `name` VARCHAR(255) NULL,
  `product_parameters` TEXT NULL,
  PRIMARY KEY (`id`),
  UNIQUE INDEX `name` (`name` ASC))
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`products`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`products` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `name` VARCHAR(300) NULL,
  `description` TEXT NULL,
  `price` FLOAT NULL,
  `oldprice` FLOAT NULL,
  `price_difference_percentage` INT NULL,
  `brand_id` INT NULL,
  `thumbnail_url` VARCHAR(255) NULL,
  `product_parameters_id` INT NOT NULL,
  `category_id` INT NOT NULL,
  PRIMARY KEY (`id`, `category_id`),
  INDEX `price` (`price` ASC, `oldprice` ASC, `price_difference_percentage` ASC),
  INDEX `fk_products_product_parameters_idx` (`product_parameters_id` ASC),
  INDEX `fk_products_category1_idx` (`category_id` ASC),
  CONSTRAINT `fk_products_product_parameters`
    FOREIGN KEY (`product_parameters_id`)
    REFERENCES `mydb`.`product_parameters` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_products_category1`
    FOREIGN KEY (`category_id`)
    REFERENCES `mydb`.`category` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;



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

Код: xml
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
<param name="Цвет">черный</param>
<param name="Коллекция">Осень-зима 2014/2015</param>
<param name="Внешний материал">фетр</param>
<param name="Сезонность">Зима</param>
<param name="Ширина голенища">34</param>
<param name="Материал подошвы">искусственный материал</param>
<param name="Страна-изготовитель">Россия</param>
<param name="Unit=RU">41</param>
<param name="Пол">Женский</param>
<param name="Возраст">Взрослый</param>



вот для мужской обуви

Код: xml
1.
2.
3.
4.
5.
6.
7.
<param name="Цвет">синий</param>
<param name="Коллекция">Осень-зима 2014/2015</param>
<param name="Сезонность">Мульти</param>
<param name="Страна-изготовитель">Китай</param>
<param name="Unit=INT">48/50</param>
<param name="Пол">Мужской</param>
<param name="Возраст">Взрослый</param>



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

Задумка такая:
product_available_parameters , в ней хранятся все доступные параметры товаров (например "Страна изготовитель", "Пол", итд);

products - сами товары

category - категории товаров, в ней же есть поле product_parameters (TEXT), в ней думаю хранить все возможные параметры для этой категории в виде JSON или разделенных запятыми. Первый запрос - получаю категорию, вторым запросом выбираю все возможные параметры для этой категории, третьим запросом выгребаю товары для этой категории.

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

Как думаете, годная ли структура, нет ли чего лишнего или наоборот может чего то не хватает?
...
Рейтинг: 0 / 0
Посоветуйте схему для товаров с различными категориями и параметрами
    #38889563
ndbn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В products не понял зачем
Код: sql
1.
`product_parameters_id` INT NOT NULL,



Если важно хранить, что было в какой то момент на продукте, то нужно добавить версионность.
...
Рейтинг: 0 / 0
Посоветуйте схему для товаров с различными категориями и параметрами
    #38889605
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
boroff,

На мой взгляд, ненужное смешение технологий. Если Вы используете JSON -то зачем городить реляционные параметры, тогда уж храните и значения параметров в JSON-поле в продукте. И наоборот, если Вы хотите построить реляционную модель - то нафига тут JSON, чего бы не сделать связующую таблицу между категориями и параметрами?
...
Рейтинг: 0 / 0
Посоветуйте схему для товаров с различными категориями и параметрами
    #38889627
boroff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ndbnВ products не понял зачем
Код: sql
1.
`product_parameters_id` INT NOT NULL,



Если важно хранить, что было в какой то момент на продукте, то нужно добавить версионность.
Название поля MySQL Workbench сгенерил похоже, видимо я связь не в ту сторону показал когда лепил схему. Привязка products к product_parameters, чтобы для каждого продукта хранить список параметров.

На версионность наплевать, XML-выгрузки будут загружаться каждый день, при вставке будет обновляться только price, oldprice и категория товара (т.к. товар может быть не распределен на момент загрузки) либо добавляться новый товар, если такого не было.
...
Рейтинг: 0 / 0
Посоветуйте схему для товаров с различными категориями и параметрами
    #38889725
ndbn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну тогда присоединяюсь к Кот Матроскин.
boroffна странице категории нужно будет например вывести все женские сапоги черного цвета и такой то коллекции.

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
product_available_parameters
id  name
1  Пол
2  Цвет
----
category
id  name
1  Сапоги
----
select * 
  from products p
 where exists (select null from product_parameters pp where pp.product_id = p.product_id and p.product_available_parameters_id = 1 and lower(p.parameter_value) = lower('Женский') )
  and exists (select null from product_parameters pp where pp.product_id = p.product_id and p.product_available_parameters_id = 2 and lower(p.parameter_value) = lower('Черный') )
  and p.category_id = 1
...
Рейтинг: 0 / 0
Посоветуйте схему для товаров с различными категориями и параметрами
    #38889924
Serguei
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
boroffНа версионность наплевать, XML-выгрузки будут загружаться каждый день
Какая то куцая у вас система получится. Почему бы не хранить историю изменения цены- ничего сложного в этом нет. Делаешь отдельную таблицу: продукт, дата начала, дата конца, цена. Все!

Ну а хранить процент, на который цена изменилась, это высший пилотаж :)
Он же считается очень легко, зачем хранить?


boroffКак думаете, годная ли структура, нет ли чего лишнего или наоборот может чего то не хватает?

Еще бы еще знать, что вы там задумали (как использовать эти таблицы, кроме как загружать туда данные), вообще было бы отлично ))
...
Рейтинг: 0 / 0
Посоветуйте схему для товаров с различными категориями и параметрами
    #38890102
boroff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SergueiКакая то куцая у вас система получится. Почему бы не хранить историю изменения цены- ничего сложного в этом нет. Делаешь отдельную таблицу: продукт, дата начала, дата конца, цена. Все!Куцая она потому что сайт - это витрина товаров + поиск по ним. В прошлой версии сайта история изменения цен хранилась, сейчас все с нуля переписывается, может потом будет добавлен и такой функционал. История хранилась просто в отдельной таблице с тремя колонками (product_id, price, date). Все товары продаются на других магазинах, поэтому задача стоит в создании различных удобных фильтров и сравнениях товарах, а так же категоризация этих товаров, история изменения цен пока не особо нужна.

SergueiНу а хранить процент, на который цена изменилась, это высший пилотаж :)
Он же считается очень легко, зачем хранить?А зачем его каждый раз считать при выборках? :) Товаров будет меньше 1 млн., так что одно integer поле в таблице много места на диске не займет :)
Например надо вывести женские сапоги со скидкой от 20%, отсортировать по убыванию размера скидки. Имхо проще сразу по этому полю сортировать, а расчет процента происходит после загрузки товаров, одним запросом.

SergueiЕще бы еще знать, что вы там задумали (как использовать эти таблицы, кроме как загружать туда данные), вообще было бы отлично ))
Вот что-то похожее http://www.thefind.com/search?query=ray ban sunglasses справа там есть фильтр (магазины, цена, бренд, цвет, итд).

Кот МатроскинНа мой взгляд, ненужное смешение технологий.

Согласен, похоже я тут перемудрил.
...
Рейтинг: 0 / 0
Посоветуйте схему для товаров с различными категориями и параметрами
    #38890163
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
boroffЕсть выгрузка товаров в XML формате. В ней товары совершенно разных категорий - одежда, обувь, аксессуары. Вполне возможно, что так же будут добавлены и другие категории товаров, как например мобильные телефоны, телевизоры и тому подобное. Вот примерно то что я придумал для структуры базы (будет использоваться MySQL ):


Предлагаю лечить головную боль усекновением головы. ;-)
Вместо MySQL взять PostgreSQL.
В нем есть типы JSON и JOSNb.
По полям этого типа можно строить индексы, делать запросы, с учетом структуры JSON.
Решение, простое, быстрое и не правильное ;-)
...
Рейтинг: 0 / 0
Посоветуйте схему для товаров с различными категориями и параметрами
    #38890287
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если хотите минимум головной боли при БД-миграциях, то рекомендую для хранения доп. инфы забыть про JSON.
В JSON можно хранить только ту инфу, кот. никогда не будут искать с пом. SQL. Например некритичные комментарии, подсказки и т.п.

Применяйте EAV. Он одинаков на любой СУБД.
...
Рейтинг: 0 / 0
Посоветуйте схему для товаров с различными категориями и параметрами
    #38908098
boroff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mad_nazgulВместо MySQL взять PostgreSQL.
В нем есть типы JSON и JOSNb.
По полям этого типа можно строить индексы, делать запросы, с учетом структуры JSON.
В общем так и сделал, перенес всю базу на PostgreSQL, только вместо JSON решил использовать hstore для параметров товаров и array для тегов. Как раз и поддержка всего этого прямо в django появилась, безо всяких дополнительных модулей https://docs.djangoproject.com/en/1.8/ref/contrib/postgres/fields/
...
Рейтинг: 0 / 0
Посоветуйте схему для товаров с различными категориями и параметрами
    #38912205
Фотография Изя Кацман
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LSVЕПрименяйте EAV. Он одинаков на любой СУБД.Согласен
см. Entity-Attribute-Value Model
...
Рейтинг: 0 / 0
11 сообщений из 11, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Посоветуйте схему для товаров с различными категориями и параметрами
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]