Оцените плиз схему для учебного проекта интернет-магазина. Меня интересует насколько

эта схема будет эффективна для реализации фильтрации товаров по множеству параметров ?

У каждой Категории есть набор специфичных Атрибутов. У каждого Атрибута есть набор Опций.
Каждый Продукт имеет Параметры с конкретными Опциями.

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

Почему?

что именно "почему"?

Почему?

Почему для таких вещей не подходит и почему не самое эффективное решение

не "не подходит", а "есть варианты удобнее" любая nosql (монга какая-нибудь, например) будет в 100500 раз удобнее, а разницу в производительности подъедят пачки джоинов в слоне

Да фиг его знает. Джоины весьма быстрые в современных базах.

А два джойна это много ? Товары + параметры + опции И через where будет сопоставляться.

А монга чем удобнее?

Сопоставляться должны через on

Быстрые-то оно да, но до момента, когда пара тройка ооочень жирных таблиц джоинится

Вообще по барабану насколько они жирные пока все индексы стоят.

Любой товар в любом виде описываешь в документе с нужными параметрами

Ага. Видел. Понавешают индексов - "а чо инсерты такие медленные"

Проблема в том, что мне не удалось нагуглить как вообще такое реализуется в известных магазинах. Не знаю почему это такая тайна. Приходится придумывать самому, но потом оказалось, что это уже кто-то придумал и назвал EAV model ) но и это решение неоднозначное и готовых полноценных примеров всё равно почти нет )

отсутствием строгой структуры данных

А в чем плюс отсутствия структуры данных? Я просто думал, что это плюс.

Насколько часто у вас меняются опции?

Смешно. На ключах индексы всегда должны быть, а что там навешивают не знаю.

в больших (я.маркет, вайлдберрис, озон, ...) часто за товарами не ходят прямо в базу - там флотилия индексирующего софта с поиском (sphinx, например или похожее)

А что их менять ? Как их вбили так они и остались. Ну вот предположим в категория "Телефоны" есть атрибут "оперативная память", который имеет опции от 2гб до 12гб. Конкретному продукту присвоена одна конкретная опция.

Ну и сколько это джоинов должно быть, если на каждую опцию - новую таблицу с ключом? Или alter-ить до бесконечности для каждого параметра?

Выйдет телефон с каким-нибудь 5-d лидаром и сканером отпечатка жопы. Как и куда добавить фильтр/поиск?

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

JSONB?

зачем брать пг для того, чтобы всё в jsonb пихать?

я имею в виду с точки зрения базы данных тебе нужно будет создать 2 новых колонки для лидара и сканера жопы и так для каждой опции =)

Есть ощущение, что у вас две лишние таблички, prop_property и property, вам в табличке products добавить ссылку на ид таблички attr_optiona. В целом даже можно убрать поле category_id, но без этого производительность запроса отображения товаров по категориям упадет.

Не надо будет, почитайте про eav.

Нет. Будет просто новая запись в таблице attributes value = "сканер жопы" И в таблице options для его будет две записи value="есть" и value="нет" 🤷‍♂🤣

Ну, это ведь от данных зависит. Никто же не будет вместо datalake брать sql. Так же и для nosql есть места, где они удобнее. Как и клик для аналитики лучше, чем influx =))

С 2015 года еще ниразу не видел полезного использования монги. Кроме кейса, надо запилить мвп за месяц, потом пофигу что будет, но даже там лучше просто в json файлы складывать))))

И для каждой категории своя таблица с атрибутами или одна таблица для овощей и автомобилей?)

Такое чувство, что работу в монги представляют как "просто пихаем куда угодно какие угодно объекты". Как потом с этим приложение будет работать, понимая, где и какие значения могут быть? В случае товаров, например, нам надо не только свойства товара вывести, но ещё и знать в этой категории товаров какие могут быть свойства для фильтрации. Всё равно модель будет описана так или иначе. Аналогично на SQL это не обязательно будет в виде кучи join-ов, можно отдельно вытасикать нормальзованные данные

https://www.mongodb.com/who-uses-mongodb

Для учебного проекта интернет-магазина хватит "базы" в xml документе. nosql (пусть будет scylla, чтобы от монги отстали) в виде "пихаем что угодно" и просто ищем что нужно - enough

Не понял, как это отвечает на вопрос

Как потом с этим приложение будет работать, понимая, где и какие значения могут быть? -- А как приложение понимает, что это нужный json?

На уровне приложения приходится поддерживать структуру?

Что тебя так эта тема со сканером то зацепила?

Для каких сайтов он годный? Я думаю, что для соц сетей, мессенджеров. Если данные слабоструктурированы. А тут создать реляционную бд и норм будет) p.s. @thephoenixofthevoid, хорошо шаришь в jsonb?)

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

Ну я вот представляю это что юзер выбирает категорию, ему с сервера подтягиваются атрибуты связанные с этой категорией и их возможные опции, тыкая по которым, юзер формирует query string, которая будет уходить на сервер, брать из базы массив продуктов с выбраными опциями. 🤷‍♂

Это вариант со схемой (о чем выше Григорий спрашивал). Есть schemaless подходы (обычно в контексте сериализации), когда вместе с данными ещё и метаданные есть. Схемалесс обычно медленней, но проще и более гибкое решение в плане экспериментов.

В целом я изначально предложил вариант "тяп ляп" MVP на колненке именно магазина как конечной цели. Если цель учебного проекта разобраться в реляционный базах, всяких там декартовых произведениях и прочей шелухе - пиши свою ToySQL (шутка).

Нет цель сделать полноценный fullstack проект, чтобы хвастаться на собеседовании на фронтенд ибо todo list никого не удивит ахах )

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

Для фронтеднера товары хранить нужно в localStorage =)

Это так не сработает если ты на фронта метишь, то разработка бека тебе никак не поможет Даже повредит, так как вместо того что бы проблематику фронта изучать ты время на никому не нужный бек потратишь если сильно бек нужен, то просто сделай моковый слой АПИ у тебя все равно ДЕМО проект будет простую логику содержать

Увы с моками я не смогу фильтровать товары по множеству параметров, делать jwt авторизацию и тд

кто тебе такое сказал?

ты с моками можешь сделать абсолютно все, кроме мультипользовательского режима

вот календарь на моках http://89.108.88.53:82/

Ну вот допустим у меня замокан массив из 20 телефонов, каждый из которых имеет 50 свойств как мне из них на клиенте найти те у которых 256гб хранилище, ips экран, usb-c, Snapdragon цп и камера на 48мгп и тд ? ))

элементарно используй метод filter у массива

Но количество условий всегда разное

это простейшая задача на JS

урыыыл

ну реально отфильтровать массив из 20 элементов по условию вернуть из мок апи слоя промис это же не высшая математика, делов то...

Мокапи поддерживает такон

Не по условиЮ, а по условиЯМ. Кондишены же динамические. Может быть 3 , а может быть 33 параметра.

Ты бы использовал эти кондишены для запроса в апи, используй их для фильтрации данных и все🤔

ну и что? у тебя есть функция АПИ, которая на самом деле данные берет не из реального АПИ, а из localStorage при вызове тащит массив из localStorage, далее фильтрует его по параметрам которые ты в нее передал и возвращает что то типа Promise.resolve("результат фильтрации данных")

можешь еще для эмуляции задержки добавить такую функцию export const delay = (delay: number): Promise<void> => new Promise((resolve) => setTimeout(resolve, delay)); ... await delay(500) будет задержка ответа апи на 500 мс

Ну это понятно. Но одно дело прислать самому себе массив, а другое когда юзер натыкал рамдомные свойства и по ним надо отфильтровать объекты в массиве.

ты не можешь отфильтровать массив по заданным критериям?

Могу когда они повторяются или имеют фиксированное количество.

а в чем проблема отфильтровать если их кол-во не фиксированное?

Я не могу динамически подставлять в if разные условия. Оно либо есть, либо нет

Так принцип фильтрации не меняется, разница лишь в том что не нужно будет с реальной БД маяться

Зато БД за меня будет все искать и фильтровать.

ну у тебя просто недостаточный уровень алгоритмической подготовки на самом деле это делается просто

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

даже фронту стоит понимать как работает бекенд особенно больше чем джун

В его случае это бесполезная трата времени

скинул пример в личку