Есть задача объединять прайсы разных поставщиков, но они разные по логике и структуре. Формат конвертнуть не проблема, а вот что делать со структурой и логикой не понятно.
Первая проблема, как определить рубрику для товаров, у все поставщиков разные вложенности и названия рубрик.
Вторая проблема, как понять что товар один, если он написан у всех по разному.
Подскажите пожалуйста, что можно почитать(посмотреть примеры) по поводу объединения разных структур(деревьев)?
Сделать под каждого поставщика свой обработчик — в принципе выход, но хочется чего-то более универсального.
Мы, например, в своем проектелюбойпрайс приводим к единой пятиколоночной структуре:
1. Идентификатор
2. Наименование и описание
3. Минимальная цена
4. Максимальная цена
5. Примечание
Когда сделаете универсальное поймете, что нужно в итоге подгонять под каждого поставщика. Лучший способ — сделать универсальный синхронизатор", но под каждого поставщика отдельно настраивать. Иначе Вы получите массу проблем. Как понять что товар одинаковый — тут уже нужно смотреть что за товары и подстраивать поиск совпадений. Не пытайтесь написать экспертную систему — это всегда хуже узкоспециализированной задачи. Если вы конечно не готовы это вылить в отделенный продукт по поиску похожих товаров.
Скорее всего у Вас будет максимум 5 прайсов. Не 100 ведь? Поэтому, я Вам очень рекомендую воспользоваться тем выходом из ситуации который Вы хотите обойти. Не делайте универсальной задачу там где она Вам больше не понадобится.
Если-бы было 5, было-бы все проще. А так их десятки.
И постоянно новые прибывают.
Причем у многих нет даже внутренней нумерации, и куча названий одинаковых, что по строке не поискать.
А есть такие, что каждый раз прайс переделывают, то поля местами поменяют, то в названия товара цвета или материал добавят и т.д.
В конце девяностых запускал аналог прайс ру в одной из банановых республик. Сейчас возможно пришло бы в голову что то и другое, но тогда делал так. Начал разрабатывать свою собственную базу товаров со своей структурой. Посадил человека, который вначале вручную вбивал все в нашу базу делая, сопоставляя пункт из нашей базы с пунктом из прайса. Потом пошли дальше, сделали таблицы синонимов. В итоге, через несколько месяцев такой работы, где то 80-90 процентов прайсов вбивалось и сопоставлялось полностью автоматически, оставшиеся 10-20 процентов увы так же в ручную. Шестью годами позже подобную задачу решал при написании биллинга для классической и айпи телефонии, но там была привязка к кодам, так что все было проще…
Занимаюсь чем-то похожим примерно треть своего рабочего времени последние 5 лет. Около 30 различных поставщиков, состав меняется и растёт. Ассортимент — одежда, бельё, чни.
В начале делал на каждого поставщика индивидуальный обработчик, потом бросил. Даже крупные брэнды регулярно меняют формат — от расположения колонок и схемы наименования товара до деталей названия каждой конкретной тряпки. А нам было очень важно что бы в нашу базу один и тот же товар попадал всегда одинаково. Получилось, что я дольше проверял правильность выхода и переписывал алгоритмы на каждое изменение чем пользовался ими. В итоге для нескольких стабильных поставщиков есть персональные загрузчики разбирающие входной файл, а для большинства только ручками пополняемая база вида «длинная строка в свободной форме из накладной поставщика» -> набор наших внутренних полей. Приведение формата файла к пригодному к такой обработке тоже полуруками.
Некоторых даже в такую форму загнать не получается.
Впрочем, если не страшны постоянные задвоения строк, то всё становится резко проще.
