В случае с signature file, каждое слово получает свой бит, количество
записей соотв. количеству слов.
И какого размера будет эта сигнатура для моих 700 тыс уникальных слов?
Ну возьми себе что-то размером с 1024 бита (например CHAR(128))...
ну и 700 тыс. уникальных слов что-то мне не очень верится... если же у
тебя различные формы склонения и во множ. числе дают разные лексемы, то
этому можно помочь - ведь этап "послефильтрирования" для signature file
обязателен.
на числе 100 тыс. _нормализированых_ лексем (единств. число, окончание
нафиг) и при сигнатуре 1024 бита у тебя будет где-то 100 коллизий на бит.
И опять же - а как искать по ней искать. Тут же, кажется, речь идет
про AND сигнатуры для строки поиска и сигнатуры объекта в БД. А это
"тупой" перебор всех сигнатур.
угу, тупой перебор маленьких записей из маленькой таблицы - отталкиваясь
от 100 тыс. записей будет где-то около 4000 тыс. страниц (может и того
меньше).
б) тебе не придется мучится ни с джойнами на больших таблицах, ни с
генерацией пар слов. Что-то мне подсказывает, что если создать три
"подписи", одну для ФИО, одну для адреса и одну для паспорта,
Ну "текстовые индексы" для адреса, паспорта и ФИО, у меня, формально,
уже разнесены по отдельным "секцияv". Этих секций, грубо говоря -
столько сколько всего всех проиндексированных объектов - 2810457. По
сигнатуре на каждый объект. Перебор трех лимонов - это не многовато? А
в перспективе? Хотя, конечно, перспектива моих комбинаций, без
внедрения "запрещенных" комбинаций - тоже пока не радужная :)
хммм... многовато... наверное тестировать надо - ведь размер перебора
зависит только от числа объектов в базе, а от количества слов в фразе - нет.
