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

Question

[Arman Baelov]

Расскажите как проработать структуру базы данных товаров. На сайте будут разные категории от одежды до электроники. Там будут десятки разных вариаций опций таких как цвет, размер + еще характеристики.

Варианты которые есть:
1. Каждую отдельную вариацию добавлять как отдельный товар. Пример: Есть 6 одинаковых платьев по фасону но с разными цветами, размер XL, 1 красное XL, 1 черное XL, 1 белое XL, 1 синие XL, 1 зеленое XL. И все эти вариации добавить как отдельный товар. (В общем ничего сложного нет)

2. Через промежуточные таблицы совместить все вариации в одном товаре, с возможностью выбора цвета и размера. (Если этот вариант самый оптимальный, посоветуйте как его можно реализовать), (https://ru.aliexpress.com/item/-/32835374867.html?... вот пример то о чем я имею ввиду)

Как это все можно реализовать максимально эффективно, или есть еще другие варианты организации такого рода задачи?

Answer 1

[Максим Федоров]

UPD: Что-то я упустил, пошел думать...

3 нормальная форма, классика жанра
И сделать денормализацию

products [id, name, ....]
variants [id, product_id, type, require, price (?)]

product_characteristics [id, name,sort,...]
product_values [product_characteristics_id, product_id, value]

variant_characteristics[id, name, sort,...]
variant_values [variant_characteristics_id, variant_id, value]

Описание:
Есть товар, у него есть варианты в таблице variants
Так как у вариантов не известно сколько будет полей (а скорее всего очень много), то выносим эти поля в таблицу variant_characteristics с связующей таблцей variant_values , то есть это связь многие ко многим.

Например: есть варианты с выбором размера и длины, то в таблице variant_characteristics заводим эти значения, а в таблице variant_values указываем id этих значений, id варианта и само значение

* Важно:
если на цену не влияют характеристики, то цену прямо варианту задаем в variants, если влияют (например XL стоит дороже XS), то писать ее в variant_values

Это называется EAV https://en.wikipedia.org/wiki/Entity%E2%80%93attri...
Характеристики товара тоже будут также сделаны, но там будет уже не вариант товара, а сам товар.
Картинки также делаются.

Comments

[Arman Baelov]

3?

[Максим Федоров]

Arman Baelov, да

[Arman Baelov]

Максим Федоров, можете пожалуйста по подробнее рассказать про ее структуру?

[Максим Федоров]

Arman Baelov,
выше схему набросал

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

Например: есть варианты с выбором размера и длины, то в таблице variant_characteristics заводим эти значения, а в таблице variant_values указываем id этих значений, id варианта и само значение

Это называется EAV https://en.wikipedia.org/wiki/Entity%E2%80%93attri...

Характеристики тоже будут также сделаны, но там будет уже не вариант товара, а сам товар