Всем привет. Есть задача агрегации товарных позиций из прайс листов

(это прайс-листы автозапчастей).

Например есть 10 поставщиков. Они предоставляют таблички с полями производитель и модель каждый день (к примеру, но вообще там разное время обновления). И вот у всех поставщиков может быть та же деталь правда с другими ценами/другими полями.

Мне нужно отдавать клиенту актуальное состояние. А для этого нужно понять как это всё хранить и обрабатывать.

Сначала я думал хранить в реляционной бд кортежи с композитным ключом из полей поставщик, производитель, модель. Вот например пришёл прайс лист, мы по композитному ключу сделали апдейт/апсерт. Но тут возникает проблема, а что если поставщик удалит какой-то товар?

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

Потом подумал в сторону документных БД, и с каждой обновой тупо удалять все вложенные товары по производителю и вносить все новые. Но это скорее всего плохо и ненадёжно (особенно учитвая лимит на 16МБ документа в монгоДБ).

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

> Но тут возникает проблема, а что если поставщик удалит какой-то товар? Ну так поступите с этим товаром так, как нужно в модели (удалите или сделайте поле с timestampt внесения). А выбирать только из-за этого NoSQL — это безумие, IMHO. ;)

"Дальше я подумал" -- это очень хорошо, это ключевые слова для правильного подхода к решению проблемы. От нас только не жди это решение

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

Вставлю и свои 5 копеек. Задачу можно решить на любой модели данных (реляционной или nosql или графовой или еще какой) тут только вопрос как будет удобно конкретно вам, переделать вы всегда успеете. В любом случае вам прийдется обучаться по ходу дела. То ли пониманию и управлению реляционной моделью и соответственно базой данных. То ли впринципе архитектуре добавления, изменения и удаления ваших данных. От себя могу добавить только то, что прайс листы от ваших партнеров это одни данные и имеют свой вид у каждого конкретного. А у вас эти данные будут уже иметь другой вид и как вы их будете перегонять из одного вида в другой - зависит от ваших знаний и умений и от кучи других параметров, а т.к. у вас это впервые, то можно поступить проще для вас, потому что сроки, или же по best practice, но тогда это будет дольше по срокам. Данные которые вы будете показывать клиентам это еще один вид данных и выглядеть будут иначе, т.е. их преобразование из ваших данных это тоже отдельная история и тоже нужно учитывать кучу параметров - сроки разработки, бюджет на сервера, бюджет на дбс и т.д. P.s. если бы делал я, то это была бы реляционная модель по первой (т.е. в первой версии, пока мало что известно) просто потому, что где с оптимизировать - потом станет ясно из уже работающего прототипа и все узкие места тоже будут известны. А вместе с реляционной моделью использовал еще какой-то кэш. P.p.s. может вам стоит еще глянуть в сторону заказать консультацию дба, который вам поможет в нелегком решении 😏