Как создаются варианты одного товара в БД?

Question

[Alexander]

Здравствуйте, очень нужнен ваш ответ, уже 3 день ищу инфу как создать несколько вариантов одного товара в БД,
чтобы создать подобный фунционал, пример на фото

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

Product.hasMany(ProductVariant, { as: 'variant' })
ProductVariant.belongsTo(Product)

На выходе я получаю:

{
            "id": 1,
            "name": "Nike air max 97",
            "createdAt": "2021-10-06T20:19:26.898Z",
            "updatedAt": "2021-10-06T20:19:26.898Z",
            "variant": [
                {
                    "id": 2,
                    "title": "Nike air max 97 Black Edition",
                    "img": "dbc1cd8a-e246-4001-a748-a4fed4678c6f.jpg",
                    "color": "purple",
                    "price": 190,
                    "createdAt": "2021-10-06T20:19:26.924Z",
                    "updatedAt": "2021-10-06T20:19:26.924Z",
                    "productId": 1
                },
                {
                    "id": 3,
                    "title": "Nike air max 97 Purple Edition",
                    "img": "f9bce92c-da44-4b95-ba51-a38aa8e479bc.jpg",
                    "color": "purple2",
                    "price": 200,
                    "createdAt": "2021-10-06T20:23:00.826Z",
                    "updatedAt": "2021-10-06T20:23:00.826Z",
                    "productId": 1
                }
            ]
        }

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

{
                    "id": 2,
                    "title": "Nike air max 97 Black Edition",
                    "img": "dbc1cd8a-e246-4001-a748-a4fed4678c6f.jpg",
                    "color": "purple",
                    "price": 190,
                    "createdAt": "2021-10-06T20:19:26.924Z",
                    "updatedAt": "2021-10-06T20:19:26.924Z",
                    "productId": 1
                },

Но теперь понял что еще нужно добавить навигацю переключения цветов, то бишь переход на стругую разновидность этого ж товара
Даже не знаю как это подробно объяснить, но я хочу сделать аналог adidas, по фунционалу с переключением разновидности одного товара.
Буду очень признателен за помощь

Comments

[galaxy]

Вопрос абсолютно не про проектирование БД. Данные вы из БД получили - дальше дело бекэнда и фронтэнда по отображению.

[Alexander]

galaxy, лучше б способы решение написал, а не докапывался то тегов

[Rerurk]

У товара есть id, есть куча свзянных таблиц, из них и собирайте то что вам нужно

[galaxy]

Alexander, у тебя проблема не только в тегах. И вообще, ты же понимаешь, что ты задаешь вопрос просто не тем людям? Будут читать спецы по БД и закрывать, ибо хрень

[Alexander]

galaxy, по твоему этот вопрос не связан с БД? Связи моделей, поиск по разновидностям модели, фильтрация данных, это про БД?

[galaxy]

Alexander, нет. У тебя нормальная структура БД, не вижу смысла ее мусолить.
Для одной страницы с вариантами вся фильтрация силами js делается

[Alexander]

galaxy, я просто одного понять немогу, как зачастую решают подобную задачу?
Подгружают список всех вариантов товара вместе с текущим через два запроса к серверу чтобы показать все доступные цвета к примеру или делают все нужное через один запрос благодаря БД?

[galaxy]

Alexander, я бы сделал два запроса - на товар и на вариации. Собрал бы все это в один JSON и отправил на фронтэнд, а он уж пусть там рисует, как хочет. Один запрос при такой структуре БД (а это вполне хорошая структура) - это джойн и дублирование полей. Да, в некоторых СУБД сейчас можно прямо за один запрос из вытащить JSON прямо в нужном виде, но я бы так не делал

Answer 1

[romaro]

Я в свое время разделил сущности товарной карточки (GOODS) и товарной позиции (PRODUCT). Товарная позиция является объектом складского учета (т.е. физически находится на складе), а товарная карточка всего лишь группирует эти позиции удобным способом и хранит фотографии, название, но не характеристики.

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

Поэтому при выгрузке из учетной системы я создавал третью сущность (ITEM), которая "виртуализировала" таблицу GOODS_PRODUCT. Таким образом, на сайте магазина у меня были GOODS и ITEM.goods, причем для ITEM.product был настроен уникальный индекс (для одного магазина нельзя было создать две карточки, на которые ссылается одна и та же товарная позиция).

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

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