Дано:
- Интернет-магазин
- Поставщики товаров, которые дают доступ к постоянно обновляемому прайсу. Разные поставщики, разные форматы прайсов, разные коды товаров.
Разные названия товаров.
Собственно, сам вопрос:
Как логично, правильно и понятно обработать кейс, когда:
Сегодня работает ссылка 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, буду рад услышать.
Средний
Простой
