Как логически правильно реализовать слияние сущностей в работающей системе (много букв)?

Дано:
- Интернет-магазин
- Поставщики товаров, которые дают доступ к постоянно обновляемому прайсу. Разные поставщики, разные форматы прайсов, разные коды товаров. Разные названия товаров.

Собственно, сам вопрос:

Как логично, правильно и понятно обработать кейс, когда:
Сегодня работает ссылка site.com/products/1 и site.com/products/2
А завтра товары объеденины и работает только site.com/products/1
(Не берем во внимание алгоритм выбора наиболее подходящей цены/наличия/описания/характеристик и т.д..)

Создать модель, которая будет следить за изменениями каждой пары товаров и хиранить в себе редиректы? Или есть более человеческий способ ?

Подробное описание задачи и постановка вопроса:

Представим, что есть система, которая постоянно скачивает прайсы со всех поставщиков и создает в системе сущности вида PriceItem.
Пускай, сущность PriceItem имеет аттрибуты: name, price, stock, supplier, code, для конкретики.

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

Сведем нашу задачу к необходимости у Product постоянно поддерживать актуальными аттрибуты price и stock (На основании значений PriceItem).

Казалось бы, нужно просто для каждого PriceItem создать сущность Product. Но тут начинаются вопросы. У разных поставщиков один и тот же товар может называться немного по-разному (Ноутбук Macbook 13" и Macbook Air), а мы хотели бы что бы в системе существовала только одна сущность Product, но она была связана с двумя сущностями PriceItem от разных поставщиков.

Так как названия не идентичны, обычным сопоставлением тут не обойдешься, нужны какие-то метрики. Представим, что у нас реализован алгоритм сравнения названий.
Я вижу два "принципиальных" варианта решения:
1) Каждый раз, как мы добавляем в систему новый PriceItem, мы проходимся по всему списку Product и пробуем определить совпадающие сущности. Не нашли - создаем новый Product на основе PriceItem, нашли - добавляем PriceItem к существующему Product.


2) При обработке прайсов от поставщиков создавать Product на каждый PriceItem. Позже, в фоне, параллельно, потихоньку постоянно искать соответствия и матчить PriceItem, привязывая к Product.


Минусы первого решения:
1) Матчинг похожих товаров блокирует обработку прайсов поставщика (которая должна проходить регулярно и чем чаще\быстрее, тем лучше)
2) Все-таки это довольно длительная операция, которую как-то неправильно производить при добавлении каждой новой сущности PriceItem, счет которых может идти на миллионы.
Плюсы:
1) Казалось бы, с таким подходом, вероятность появления двух разные Product, которые будут одним и тем же товаром, просто от разных поставщиков с немного измененным названием - крайне мала. Однако, мне кажется, не все так хорошо и алгоритмы все равно со временем претерпевают изменений и если сегодня было решение отнести 2 PriceItem к Product A, то завтра есть вероятность, что после смены алгоритмы один из них все же будет принадлежать Product B (то есть, не такой уж и большой выигрыш в точности, на мой взгляд)

Плюсы второго подхода:
- Есть возможность сделать процесс постоянным и максимально распараллелить.

Если сильно перемудрил и есть более простые варианты реализации "принципиального" подхода маппинга PriceItem на Product, буду рад услышать.
  • Вопрос задан
  • 2378 просмотров
Пригласить эксперта
Ответы на вопрос 1
@DancingOnWater
Увы не специалист в этой области, но ваша проблема похожа на BigData.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы