Вопрос, наверное, о максимальном количестве записей в справочнике. Где хранить, например, несколько миллионов записей об запчастях?

Задача: хранение большого количества пар "Наименование товара" - "ID товара". Либо, при наличии нескольких источников, хранение записей "Наименование товара" - "URL источника" - "ID товара в источнике". Точной формулировки задания пока нет. Цель - составление товарного каталога автозапчастей. Источники - общедоступные каталоги в сети.

Конфигурация: разработка "с нуля", специально оптимизированная для хранения большого количества записей.
ПО: SQL Server 2008 R2 SP1

(0) Ну ежели у тебя нетленко и УЖЕ "специально оптимизированная для хранения большого количества записей", тогда что ты тут делаешь? Хвастаешься?

Хранить - пофигу.
А вот обращаться и работать с ним...

а мощности связей какие нужны? если многие ко многим - три таблицы - 2 спр + 1 рс.

обязательно эту дрянь в 1с тащить? пусть снаружи в sql валяется...

(0) Не парься. Справочник для сабжа однозначно удобней, а РС не настолько экономней, чтобы ради этого чем-то жертвовать.

(1) слово УЖЕ вы написали
(4) >обязательно эту дрянь в 1с тащить?
Согласен с тем, что тащить результаты парсинга в рабочую базу в номенклатуру не нужно. Поэтому я подумываю об отдельной базе 1С, специально оптимизированной для хранения большого количества записей.

(5) то есть справочник, где 5 миллионов записей, может существовать?

>Поэтому я подумываю об отдельной базе 1С

зачем она должна быть базой 1с?

В базе 1С хранится только то, что было заказано. Подбор по марке, модели, году, вину - в отдельных актуальных обновляемых БД. Они разные, с разной защитой, за разные деньги.

Обновлять свою БД ты же не будешь? Значит, она будет И большой, И неактуальной в части подбора.

(6) На практике не встречал. Про пару миллионов слышал. Явных ограничений на количество элементов не существует. Как и каких-то специфичных для справочника механизмов, генерирующих тормоза пропорционально количеству элементов.
В конце концов, это элементарно проверяется на практике.

(7) это точно должна быть конфигурация 1С, так как придется решать много типичных для 1С задач - обмен данными и т.п.
Но то, что сами данные - вот эти здоровые таблицы с товарами -должны храниться именно в 1С я не утверждаю. Возможно, таблица товаров может храниться непосредственно в SQL. Но тогда вопрос - а это точно лучше, чем хранить данные средствами 1С?

Продолжу (8). Это если у тебя розница.

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

(9)"На практике не встречал. Про пару миллионов слышал."
автозапчасти иномарок влегкую дают 15-40 млн.
Промышленные системы Европы (САП так нелюбимый одноэсниками) тянет и обрабатыввает это влегкую (2-5 сек в базе сайта с запросом к основной удаленной базе данных).
1С - шуршит до 15 минут, а то и вовсе отлуп дает, не могу, дескать, обработать столько всего...

да лана че такого, из рабочей базы http://imglink.ru/show-image.php?id=2ac18062680129e3077824245fe08f87

у РС индексирование сразу на измерения а у справочника... а индексы надо еще обновлять при записи...а оно надо ?

Извините, я должен отъехать. Тему не бросаю, вечером вернусь.

(0)"генерирующих тормоза пропорционально количеству элементов."
динсписки, нет? Не спецтормозной механизм при отображении?

(10) В плане специфичных алгоритмов подбора и поиска - непосредственно в SQL гибче. Можно настроить нужные индексы и реализовать оптимальные по производительности алгоритмы.
Если логика использования больших классификаторов прозрачна и ограничена, то в 1С их держать смысла нет.

(10)"Но тогда вопрос - а это точно лучше, чем хранить данные средствами 1С?"
потому что 1С не предназначена хранить и обрабатывать гигантские объемы сообразно приведенным уровням.
Как пособие по учету для ларьков - самое оно.

(16)
1) динсписки сами по-себе тормозят в зависимости от размера таблицы? Чорд. Я я-то думал их придумывали для прямо противоположного. Не, если конечно нафигачить в запрос-источник кучу соединений по неиндексированным полям, можно многого достичь.
2) не факт, что они нужны

(17)"то в 1С их держать смысла нет."
в 1С с ними просто невозможно работать нормально (при таких объемах), т.к. реальных механизмов оптимизаций поиска в 1С нет.
Так, декларации о "индексации"...

(19)"динсписки сами по-себе тормозят в зависимости от размера таблицы? "
то, что там список постоянно "запросит" - это как-бы за рамками?

(6) Ну есть у меня справочник на 12 миллионов записей. Не запчасти. Полет нормальный. Реструктуризация только долгая, если нужна.

(21) И чо? Он по-разному запросит в зависимости от размера таблицы? Или запросит неоптимально, ежели разработчик не "помог", конечно?

(12) "Ох уж эти сказочки, ох уж эти сказочники" (с)

Просто если уже есть мысли о выносе классификатора в отдельную базу 1С, то обойтись вообще без 1С - гемора уже не добавит.
А гибкости и производительности - добавит.

(22) не гони на 12 млн не сделаешь ты реструктуризацию, недельку покурить надо после запуска

это да... реструкторизация на таких базах - просто песТня... то что скуль делает за минуты 1с буробит сутками

Дык у 1С тупая схема схема реструктуризации. Он же полностью копию таблицы готовит и лопатит. Ессно, что самому можно на порядки оптимальнее реализовать для прозрачных случаев.

(26) Длительность реструктуризации помимо количества записей зависит от мощности сервера, величины одной записи и ряда других факторов. в моем случае 12 часов хватает.

(29) Ага и 12 часов никто не работает в базе

РЕструктуризацию огромных таблиц можно и нужно делать прямыми руками, а не полагаться на рукопопие пейсателей платформы.

(30) + и регламентные задания не выполняются

(31) нарушение лиц соглашения?

(33) Восстановление здравого смысла

а как приятно было получить граблями по хребту - нехватка памяти после пары дней ожидания

(35) гы, +100

(1) "специально оптимизированная для хранения большого количества записей. " - SP, индексы, insert`ы, update`ы?

(37) да не, просто кроме этого справочника ниче больше нет =)

(38) :). Если структура разработана - в принципе, хранить все равно где, обращаться для скорости лучше через SP. Индексы и на табличках 1с можно достроить ручками.

(30) А вчем проблема? Далеко не все организации работают в режиме 7x24. У нас остановить систему на выходные (если это происходит не каждые выходные, а досточно редко) проблемы особой нет.

(39) Ну да, можно и индексы ручками достроить и прямые запросы писать, только в большинстве случаев это даже не нужно (хотя случаи конечно разные бывают и нужно быть готовыми).

(12) http://imglink.ru/show-image.php?id=a7cda400c7de00c8e8b1eec2a8265f81

Только внешняя база. Без вариантов. Иначе намучаетесь с бэкапами и реструктуризацией. Прикиньте, сколько будет идти выгрузка в dt и ремонт базы.

Я работал с таблицей в 40 млн записей, держал ее в отдельной БД.

(42) у вас все запросы на количество? Тогда поздравляю, будет все летать.

(0) несколько миллионов это немного

справочник нужен ТОЛЬКО тогда когда нужна ССЫЛКА

Не знали наши мамы
Не знали наши папы,
Что дети не простые
У них в семье растут.

(44) проблема внешних баз-справочников в том, что информация из них постепенно переносится в основную базу учета заявок/покупок/продаж, и вопрос только в том, какой процент внешнего справочника переползёт в основную? По ответу и судить, как хранить на будущее.

(49)я думаю из внешнего справочника переползет в основную базу учета заявок/покупок/продаж 1%-10%

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

(50) тогда внешняя СКЛ-база и подходы уже описали выше бывалые коллеги.

коллеги, не дайте умереть в темноте и невежестве.. чего-то меня не штырит/штырит когда вижу типа запись:
> у РС индексирование сразу на измерения а у справочника... а индексы надо еще обновлять при записи...
//
это как "индексирование сразу  на измерения" - типа из ниоткуда индекс по ищмерениям обновился при записи? а у справочника что - как-то иначе?

Упертый автор, ему отдельная нужна, для хранения большого кол-ва... база... на 1С :)

(53) Так же как и в семерке - для регистров куча муеты... распухент по самые помидоры база, а муета будет тормозить при записи и апдейте
А ведь можно красиво создать то что нужно, скл как-то справляется с такими объемами

Вообще апдейт регистра сведений ср-вами 1С это полный звиздец... при наличии нормальных, простейших и быстрых инструментов SQL

(53) "это как "индексирование сразу  на измерения""
это всего лишь значит, что у РС ключ создается и индексируется по измерениям, а у Справочника - по жестко заданным стандартным полям.

(45) нет, я тебе показываю сколько записей в РС. Это рабочая база, в ней работает около 700 пользователей,я думаю ты знаешь как используется регистр Версии объектов и какие запросы к нему идут.

(58) точнее не пользователей, а активных подключений

DexterMorgan Хм Шибанов Алексей

Пусть делает внешний коннект к, допустим, MongoDB. Если хочет поэкспериментировать. Либо просто табличку сделает в MsSql-e. Какая-то расплывчатая тема.

(57) а какая разница для записи?

(60) Неа)

(0) В плане производительности наверное разницы между справочником и регистром сведений нет. Дело в другом, если тебе ссылки на элементы нужны то однозначно - справочник, а так РС лучше.

(64) почему РС лучше?

(61) нормальная тема)
+(65) присоединяюсь к вопросу. тоже слышал об этом, но, наконец, хотелось бы узнать - а почему же РС лучше?

можно поиграть измерениями (индексами), добиваясь большей селективности

необъектная модель записи РС несколько быстрее - нет никаких проверок ссылочной целостности например при штатном удалении позиции, нельзя задвоить данные по измерениям (в справочнике - элементарно, проверки прописывать самому) и прочие приятные мелочи...
но нет ссылки, хотя в принципе никто не мешает прикрутить справочник на используемые элементы и ссылку на него в ресурс кинуть

(47) +1

Для большого количества данных есть еще один важный момент, о котором не часто упоминается.
Если в справочнике есть табличная часть, то количество строк в ней не может быть более 100000
В базе, где будет много данных и в ТЧ будут так же что-то храниться не стоит об этом забывать.

Еще у меня есть отдельный вопрос: если все-таки хранить информацию в Справочнике и позиций 5млн. (цифра взята от потолка), то не будет ли лучше создать 10 справочников (с одинаковой структурой) и хранить в каждом по 500.000 элементов? Вопрос именно о производительности (от логики такого решения временно абстрагируемся).

в MSSQL есть настоящий полнотекстовый поиск,
а не такой бесполезный как в 1с.
Хотя бы ради полнотекстовых индексов надо хранить огромные базы на MSSQL :)

(71)
правила нормализации баз данных запрещают делать такую хрень
"10 справочников (с одинаковой структурой)"

(73) Жизнь не загонишь в правила. Пример: каталог Яндекс-Маркет. Для разных категорий товаров структура товаров отличается. Готов поспорить, что не в одной таблице Яндекс хранить сотовый телефоны и детские игрушки.

(74) смотря как она описывается. может это тупо кусок xml

(65), (66) Это как вопрос: А с чем в лес за грибами лучше ходить, с чемоданом или с сундуком. Ответ - это смотря за какими грибами...

(0)  Можно и в справочнике . Почему нет. Индексируйте поля поиска .

+(77)  убедитесь штаа оптимизатор  юзает именно их .

Вопрос  опять политический . А на выходе все сводитяс к обычной таблице.

Я бы задал вопрос с другого конца..... когда понадобится  запись в справочник то ..... наборов у него нет.

И когда  понадорбится лить 5 000 000 на вставку ....

(77) Код, да наименование - индексируются по-умолчанию в справочнике.

(82) А  другие поля  разве нельзя  индексировать ?

Если память не изменияет   индекс по полю  - на выходе имеем индекс ( ссылка-код-нименование-нашеполе) .  Ну в любом случае  на план Вам придется посмотреть.

(84) наше поле первое в индексе, а код или наименование добавляются, только если с доп. упорядочиванием.

Ну и собственно  "о максимальном количестве записей в справочнике. "  это в  мануале на ограничение объема данных SQL Server 2008 R2 SP1

(85) Возможно . Спорить не буду .  Привел как пример.

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

И .... что мало вероятно  придется ваять свой индекс  и принудительно его использовать  и прибегать к ADO.

(88) Смотря что будут запросом выбирать - если всё подряд, то зачем тогда вообще индексы нужны.

Очень советую сразу определить возможную-среднюю и максимальную длину наименования.

Иначе в случае справочника потом могут быть проблемы ну или вместо наименования использовать реквизит.

Еще если действительно миллионы и даже 10-ки миллионов записей то лучше вынести этот полный справочник во внешнюю БД например тот же Oracle весьма шустр.

А в конфигурации справочник номенклатуры использовать только для заполнения в документах.

Это можно через обработки сделать к примеру при выборе наименования открывается спец форма в которой идет поиск по внешней БД, при выборе ищется уже созданный элемент справочника номенклатуры (для ускорения можно во внешней БД хранить гуид 1с-го справочника) если не найден то создается по выбранным данным.

Это самый оптимальный по быстродействию вариант.

(90) в 5 000 000 таблице  уж должны будут ... Да если и не будут отбор и так стоит по условию ограничения вывода на экран. Дейстивтельно пока на экран вывод 5 лямов - это долго :)

(92) Если выводить "в кадре запроса", то моментально - только то, что поместилось на экран. Но, если кто-то хитрый отбор включил, то сервер немного подумает, прежде чем родит ответ.
Другое дело, надо ли это ?

Хотя, прямое сканирование 5 млн записей - это получается где-то 5 секунд, если не требуется установка блокировок и прочей многосеансовой фигни.

(57) Простите темного. а что - у РС набор измерений не жестко задан?

А, я про то, что это с диска прочитать нужно забыл - 5 Гб - в 23-битах у нас полностью в память не поднимется.

(95) Нет, как раз он задан и по нему строится основной индекс. Могут быть ещё и дополнительные, по дочерним измерениям и т.п.
У справочника же основной индекс по идентификатору.
Вопрос - какой индекс будет работать быстрее - открыт.
Чай GUID - это 16 байт, а если строка, то 32 символа.
Если же измерения числа, то можно сделать работу быстрее, чем справочник.

Вижу отличия такие

Справочник:
Минусы
- Есть поле Ссылка. Т.е. размер +16 байт на каждую запись
- Индексы по коду и наименованию некластерные на кластерном индексе т.е. размер индексов соответствующий
и появляется затратный Key Lookup при поиске
- Появляются фактически неиспользуемые поля ПометкаУдаления, Версия(8 байт)

Регистр сведений:
Плюсы
- Составной кластерный индекс начинающийся с первого измерения т.е. быстрый Clustered seek по данному измерению

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

(99) для начала нужно понять как ТС собирается делать выборки
а делать он их полюбому будет, т.е. индексы понадобятся не на Коде так на другом поле

что касается справочника и его кластерного индекса на GUID то такое решение может быть оптимальным если запись будет выполнятся в несколько потоков параллельно, т.е. если есть потребность оптимизировать этот процесс

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

(102) сначала пары Наименование-ID. Потом выборочно, для некоторых пар Наименование-ID хранить свойства, картинки, дополнительную информацию (описание, цены) и т.д.

(103) Так вы определитесь с дополнительной информацией - постройте её структуру, тогда будет ясно. Просто, наименование можно хранить как наименование или строку в справочнике, а также как ресурс в регистре сведений.

(104) Первый этап - запись  пар Наименование - ID это либо справочник, либо РС, либо внешняя таблица. Таких пар вполне может быть миллион.
Второй этап - получение и хранение детальной информации. Тут пара "Наименование-ID" уже точно должна быть элементом справочника (если хранилась во внешнем источнике - то создается  этот элемент справочника). И к элементу уже через известные механизмы РС ЗначенияСвойствОбъектов цепляются свойства, через СправочникВнешниеФайлы - внешние файлы и т.п.

А может кто-нибудь вот это пояснить?
(72)
в MSSQL есть настоящий полнотекстовый поиск,
а не такой бесполезный как в 1с

Почему полнотекстовый поиск в 1С назван бесполезным?

+(106) ответ сам нашел:
Не советую использовать полнотекстовый поиск от 1С, если на то нет совсем уж критической необходимости, да и то - опционально, как "бантик". С индексацией действительно всё плохо и со стороны 1С не особо оптимизировано. Элементарный пример - мы НЕ можем управлять индексацией, индекс обновляется весь целиком или никак, а если мне сегодня и щас надо переиндексировать по одному справочнику из трёх, то фигушки. И уж частью функционала такой поиск точно делать нельзя.
http://infostart.ru/public/248090/
Неужели все так плохо??

(107) Думаю, что, в скором времени, допилят - а сейчас - он реализован, как в Windows - вроде бы есть, но работает очень странно.

(0) Большой объем - только во внешней базе данных.
1С для хранения большого объема не предназначена.

И чего все так хотят в эту 1Ску всё запихать???

Смотрите на мир шире, на 1С свет клином не сошелся. Есть много других удобных механизмов.

(108) А в SQL-то он хоть есть?)
(109) я уже догадываюсь, что мои пары Наименование-ID лучше хранить непосредственно в SQL.

Придется решать такую задачу: по заданному наименованию товара (из справочника Номенклатура) найти в моей базе N записей, у которых Наименование наиболее похоже на заданное наименование. Т.е. нечеткий поиск.

(110) туда же можешь запихать таблицу соответствий: внешнее значение -> значение в твоей базе.

(110) Ну, тогда вам вообще текстовый файл на ура будет.
Нечёткий поиск и полнотекстовый поиск - это совершенно разные вещи.

(112) был бы премного благодарен, если бы вы мне объяснили разницу между ними и что из них пригодится мне.

(113) Нечеткий - это когда по слову бл*ть ты найдёшь и женщину, и местоимение.
А полнотекстовый тебе такого не даст.

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

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

Для полнотекстового поиска создаётся база вхождений слов в наименования и другие текстовые реквизиты (или реквизиты, которые могут быть преобразованы в текст). Если мы хотим нечёткий поиск, то нужно не только базу слов, но и базу похожих на них слов, а также взаимное расположение слов.

(115) какая, на*******, база при нечётком? Там совсем другие алгорифмы...

Алгоритмы нечеткого поиска являются основой полноценных поисковых систем.

Реально, нечёткий поиск - это поисковая система yandex, хотя и там используется "замена" слов на наиболее близкое широкораспространённое, а также используется морфология и слова-синонимы.

Полнотекстовый поиск — поиск документа в базе данных текстов на основании содержимого этих документов.

(116) Ну, там тоже есть база, только в ней не просто слова, а записаны подобия, расстояния между словами, как в тексте, так и по смыслу - в общем - это отдельная тема, никак не связанная с 1С.

Эти понятия не тождественны, но являются связанными.

(119) Ну, а справочники и другие объекты мы что - не ищем ?

Полнотекстовый поиск использует алгоритм нечеткого поиска, но является более широким понятием

(121) Как бы, нечёткий поиск использует для получения результата базу полнотекстового поиска, чтобы не выбирать весь текст сразу.

Ну регулярные выражения это ж нечеткий поиск, так?

Я прикинул - миллион пар Наименование - ID в тексте займут примерно 50 мегабайт. Нечеткий поиск в файле размером 50 мегабайт быстро проводится? (и какими средствами лучше?)

(125) Нет - это просто поиск по условию - никакой нечёткости там нет - или попали в шаблон или не попали.

(126) Ну, если файл заранее разбить на слова, а потом провести нечёткий поиск по этим словам - выбрать подходящие и попросить полнотекстовый найти элементы по словам.

Из Wiki:
Первые версии программ полнотекстового поиска предполагали сканирование всего содержимого всех документов в поиске заданного слова или фразы. При использовании такой технологии поиск занимал очень много времени (в зависимости от размера базы), а в интернете был бы невыполним. Современные алгоритмы заранее формируют для поиска так называемый полнотекстовый индекс — словарь, в котором перечислены все слова и указано, в каких местах они встречаются. При наличии такого индекса достаточно осуществить поиск нужных слов в нём и тогда сразу же будет получен список документов, в которых они встречаются.

wiki:Полнотекстовый_поиск

При этом задачу нечеткого поиска можно сформулировать так:
«По заданному слову найти в тексте или словаре размера n все слова, совпадающие с этим словом (или начинающиеся с этого слова) с учетом k возможных различий».
http://habrahabr.ru/post/114997/

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

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

(128) честно говоря, не очень понял.
>файл заранее разбить на слова
Так все-таки БД или файл?

(131) В файле - строки, в БД - записи.
В остальном - никакой разницы между ними нет.
Вместо строки полнотекстовый поиск запомнит номер (или идентификатор объекта), в котором встречается слово.

Переверну вопрос иначе.
Зачем хранить в базе 1С такое количество товарных позиций? Делать отборы, запросы, отчеты, да и просто распечатывать документы? Подбор аналогов? Не проще ли по вашим каталогам сделать структуру а-ля ном.группы и уже их подставлять автоматом в нужные позиции?  А все остальное (наименование, описание, внешние файлы, картинки, аналоги, цены) дергать из внешей базы. Структура сразу сократиться в разы. Вряд ли у вас часто будут аналитические запросы по конкретным товарным позициям.  А даже если и будет стоять такая задача, то куб  все равно делать уже напрямую во внешней базе.

(110) вполне может покатить обычный нечеткий поиск из strmatch.dll Вряд ли твое наименование из 1С надо искать среди 5 млн "внешней" базы - обычно такой большой массив данных - все-таки можно существенно подсокартить - колеса искать среди группы "колеса", а не в "АКП"... на нормальном компе нечеткий поиск среди 100 тыс позиций быдет выдавать достаточно быстро - результат в пределах 1-3 сек. только таблицу для нечеткого поиск апридется готовить чуток подольше - но тут уже тоже можно вполне уложиться, если опереться на некие бизнес-регламенты или приемы работы в базе. Порядка на 30 тыс элементов - нечеткий поиск работал у меня весьма шустренько. Подготовка данных для "сеанса" нечеткого поиска - занимала меинутц-полторы - потому что не использовал прямые запросы...

(134) там ещё важно грамотно расставить важность на словах, чтобы что-то искать приблизительно, а что-то - чётко и правильно.

(134) как раз думаю про strmatch.dll.  И полностью согласен, что искать нужно в некотором подмножестве. Если не указана группа,а на входе только строка "Аккумулятор HITACHI" то пока придумал двух-этапный алгоритм: сначала в кэш strmatch.dll загнать наименования групп и искать соответствие, в данном случае это будет некоторая группа "Аккумуляторы". Вторым этапом проводить поиск среди элементов уже внутри этой группы, используя ту же ВК.

(136) Я бы ещё производителей закешировал, чтобы они не по словам искались, а по ссылкам, причём более высокая важность ставилась.

(134)"вполне может покатить обычный нечеткий поиск из strmatch.dll"
как его к 8-ке подключить? И что это такое?