Сопоставление товаров в БД?

Question

[Кирилл Горелов]

Разрабатываем скрипт по сопоставлению товаров внутри своего магазина.
Само сопоставление не проблема, у нас есть все характеристики, вопрос, в том как хранить сами связи между товарами?
Первое что приходит на ум - это связь многие ко многим. Но что-то подсказывает, что не подойдет. Особенно когда товаров будет очень много. Предположим товарная позиция разрастется до 1млн товаров вместе со всеми SKU и такая связь будет очень неудобной для работы.
И собственно вопрос, может можно еще как-то это сделать? Смотрели в сторону графовых БД, но пока не уверены.....

Comments

[Сергей Водаков]

Давайте определимся с терминами.
Что значит "сопоставляете"? Я правильно понял, что сопоставленые товары, это взаимозаменяемые?
Что вы называете товарной позицией? Как она может включать миллион товаров и почему вы SKU выделяете отдельно? Для меня, Товарная позиция, товар, элемент номенклатуры и SKU это слова синонимы, вы же явно вкладываете в них разный смысл.
Да, и собственно, для решения какой бизнес-задачи вам понадобилось настраивать эту связь? Возможно её можно решить иначе.
Если вы ответите на эти вопросы, то я могу порекомендовать вам структуру таблиц, которая решит вашу задачу.

[Кирилл Горелов]

сопоставление - похожие товары
Товарная позиция, товар, элемент номенклатуры и SKU - для меня это так же одно и тоже...

Бизнес задача, нужно от разных поставщиков показывать походие товары по свойствам, категориям и параметрам.

Answer 1

[Сергей Водаков]

сопоставление - похожие товары
Товарная позиция, товар, элемент номенклатуры и SKU - для меня это так же одно и тоже...

Бизнес задача, нужно от разных поставщиков показывать походие товары по свойствам, категориям и параметрам.

В этом случае, я бы ввел таблицы этих свойств и категорий, и затем делал бы выборку товаров по связи с этой таблицей.
Например, таблицы:
Типы категорий (cattypes): id, name
Категории (categories): id, type_id, name
Принадлежность товаров к категориям (product_categories): sku_id, kat_id
Теперь, допустим у нас есть тип категории "Инструмент". У него есть категории: "Отвертки", "Пассатижи", "Молотки".
И допустим есть тип категори "Виды отверток", с категориями: "крестовая", "звездочка", "шлицевая".
В таблицу product_categories вы делаете записи по каждому товару и каждой категории, для крестовых отвертки это будет две записи, "Отвертки" и "крестовая". (нужно больше признаков, просто добавляете новые типы и значения категорий).
В результате у вас в этой таблице product_categories будет столько записей, сколько у вас категорий по каждому товару. Для какого-то товара 5 записей, для какого-то одна, ну допустим в среднем 5 записей. Тогда размер этой таблицы будет КоличествоТоваров * 5

Comments

[Кирилл Горелов]

Правильно ли понял логику работу....

Я создаю необходимые категорию. И кладу в соответствующую категорию все товары поставщиков и при открытии страницы товара я подтягиваю товары из этой категории с параметрами текущего товара?

[Сергей Водаков]

Кирилл Горелов, да, верно, примерно так.

[Кирилл Горелов]

Сергей Водаков, не плохой вариант)
мой гораздо хуже.
А вопрос, а как мне сделать хранение параметров товаров?

Ведь у каждой категории товаров они все будут разные.
У молотков одни у отверток другие....

[Сергей Водаков]

Кирилл Горелов, ну, это уже вопрос организации интерфейса и защиты от дурака, чтобы нельзя было например сделать крестовой молоток.
Для этого вам прийдется организовать несколько служебных таблиц, по которым будет осуществляться этот контроль.
Чтобы небыло путаницы с категориями, например добавим товару атрибут: вид товара, который берется из таблицы с перечнем видов товаров.
А в таблице "Допустимые категории товара" будем хранить список категорий которые присущи каждому виду товара, а еще, например, признак обязательности заполнения (чтобы ругать пользователей за попытку это не заполнить).
Теперь мы можем контролировать, какие категории у какого товара должны быть заполнены, какие могут быть заполнены, а каких вообще быть не должно.

[Кирилл Горелов]

Сергей Водаков, Это все понятно, но я имею ввиду как к товару "цеплять" свойства.

[Сергей Водаков]

Кирилл Горелов, ну у вас есть таблица (для удобства пишу названия, хотя у вас там будут id):

sku_id, type_id, cat_id,
"Отвертка Intertool, крестовая, красная", "Вид товара", "Инструмент"
"Отвертка Intertool, крестовая, красная", "Вид инструмента", "отвертка"
"Отвертка Intertool, крестовая, красная", "Тип отвертки", "крестовая"
"Отвертка Intertool, крестовая, красная", "размер", "PH6"

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

Answer 2

[Иван Мельников]

Как я понял, под сопоставлением товаров понимается связь типа "Вместе с товаром A в x% случаев покупают товар B". Если так, то такое "сопоставление" изображается направленным взвешенным и достаточно разреженным (если в случае веса дуги 0% считать, что она отсутствует) графом.
Почему вы считаете, что таблица N:M будет неудобна для хранения такой структуры?

id_first (4 байта)
id_second (4 байта)
conn_rate (1 байт)
period_type (1 байт) -- день, неделя, месяц
date (2 байта) -- дата начала периода

Далее, делаем индекс B-tree по полям id_first и id_second .
Пусть, товаров 100 000. Для хранения всех связей за конкретный период понадобится 100 000 * 99 999 ≈ 10 млрд. строк или 90 ГБайт места + примерно столько же для индекса ≈180 ГБайт.
А периодов за 1 год = 365 + 52 + 12 = 429. Итого, для хранения годичных данных понадобится ≈ 77 ТБайт.
Понятно, что это нереализуемо.
Тогда придётся хранить дуги с достаточно большим весом. От этого вряд ли вы что-то потеряете, так как ~ 99-99.99% дуг будут иметь вес x < 0.1%.
А ещё можно оптимизировать требуемый объем, разделив данную табличку на 3: табличка для дневных данных, табличка для недельных и табличка для месячных.

Comments

[Кирилл Горелов]

чо за дуги?

а зачем мне дневные/недельные/месячные данные?