Можно ли сделать быстрее?

Привет!

Есть каталог товаров, есть куча прайс-листов в экселе, которые вкачиваются в лотус.

Написанный мной алгоритм привязки позиций прайс-листа к товарам на лотус-скрипте работает порядка трех часов на объеме 40 000 товаров и 20 000 позиций прайс-листа.

Позиции прайса выглядят примерно так:

Micro Memory Stick M2 4Gb Silicon Power
Memory Stick Micro M2 4Gb SanDisk С адаптером для Memory Stick Pro Duo
Память Micro Memory Stick M2 8Gb Silicon Power
Micro Memory Stick M2 8Gb Silicon Power + 2in1 Card Reader
Карта памяти Memory Stick Micro M2 8Gb Sandisk с адаптером Pro Duo

То есть привязка идет по ключевым словам к соответствующим товарам.

Вопрос будет ли работать быстрее если переписать
1. переписать на java агенте в лотусе
2. переписать на с-api

Также буду признателен за идеи по более быстродействующему алгоритму.

Заранее благодарю.

0

слишком туманно расписано

0

Сообщение от Gandliar Написанный мной алгоритм привязки позиций прайс-листа к товарам на лотус-скрипте работает порядка трех часов на объеме 40 000 товаров и 20 000 позиций прайс-листа.

алгоритм в студию

Сообщение от Gandliar Вопрос будет ли работать быстрее если переписать 1. переписать на java агенте в лотусе

нет
СиИАПИ - малоразумный шаг

0

Не понятен реальный объем обработки данных...
И общий алгоритм в студию)

0

Может что полезное найдётся
Сравнить вид в Лотусе и таблицу в Оракле,.

0

Переформулирую понятней

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

Таким образом в результате я получу информацию

1. есть ли товар в продаже
2. у кого из поставщиков я могу его купить и по какой цене

Таким образом задача - привязать позиции прайс-листа к правильным товарам.

товар
поставщик1, цена, условия
поставщик2, цена2, условия2
поставщик8, цена8, условия8

В позиции прайс листа обычно есть следующие поля:

1.название
2.описание
иногда
3. производитель

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

Поэтому мною был придуман следующий алгоритм:
Для каждого товара сделано многозначное поле Алиасы в каждой строке которого заданы ключевые слова.

Сейчас работает алгоритм А
1. на первом проходе по позициям прайс-листа определяется производитель
2. Затем список алиасов всех товаров закачивается в память разделенный по производителям
3. Затем для каждой позиции прайса и каждой строки алиасов заданного производителя по каждому слову ищется вхождение в названии+описание
4. Если все ключевые слова присутствуют в название+описание то позиция привязывается и происходит переход к следующей позиции

Работает крайне долго на 40 000 товаров и 20 000 позиций прайса, часами, хотелось бы ускорить.

Сейчас зародилась идея сделать немного по-другому, алгоритм Б

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

Заранее благодарю

0

Каким образом берете данные из екселя? ActiveX?
Каким образом ищете соответствие в лотусе? По вьюшке, db.search, или еще как?


В любом случае у меня есть ощущение что время можно сократить минут до 15-30. Проход должен быть только 1.

0

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

Другой подход:
Закачать все прайсы во временную БД. Построить FT-индекс. Для поиска позиций для товара использовать FT-запрос, включающий производителя и все ключевые слова.

хехель конвертить в CSV (сделать предпроцессор), иначе - прощай перформанс...
либо как предложил TIA - качнуть в БД (и не факт - что нотуса)

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

0

Прайс-листы закачиваются в лотусовую бд.

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

Попробовал локально с фтсеарчем по виду, работает гораздо быстрее. Видимо это будет самый быстрый метод.

У меня было заблуждение, что при обновлении фт индекса метод просто дает команду на обновление, но не ждет завершения операции обновления, а реально он ждет и отрабатывается правильно <_< по крайней мере на локале, надеюсь на сервере тоже.

Интересно, влияет ли порядок ключевых слов на итоговую скорость поиска.
типа

[Description] contains (samsung and syncmaster and t220)

[Description] contains (t220 and syncmaster and samsung)

если позиций содержащих слово "samsung" 3000 а позиций содержащих слово "t220" всего 3

Всем спасибо за советы! Завтра реализую.

0

Сейчас работает алгоритм А 1. на первом проходе по позициям прайс-листа определяется производитель 2. Затем список алиасов всех товаров закачивается в память разделенный по производителям 3. Затем для каждой позиции прайса и каждой строки алиасов заданного производителя по каждому слову ищется вхождение в названии+описание 4. Если все ключевые слова присутствуют в название+описание то позиция привязывается и происходит переход к следующей позиции

а ведь можно всё это сделать за один проход....

0