У меня похожий вопрос, но он касается количетва разрешенных запросов например к гуглу с одного Ай Пи. Оно вроде ограничено 1000-ю запросов в сутки.. Как быть?
Ну вот могу сказать что когда меня не удовлетворяли алгоритмы баз данных(например какая нибудь хитрая многомерная сортировка), я их реализовывал сам на уровне бизнес логики с применением классических подходов теории алгоритмов :) А вообще я думаю что у нас достастаточно разные задачи что бы мерятся в скорости...
ПС И кстати мне кажется что в том случае все таки индекс мог бы существенно ускорить выполнение запроса...
Извиняюсь наверное неправильно понял ваше сообщение...
А вообще мне кажется что такая ситуация возможна, если где то используются разреженные структуры данных(имею в виду при разработке БД), для которых действительно можно не знать без полного пересчета числа записей. Но приведенный пример имхо не сильно критичен...
Да ну, в запросе:
select count(*) from tablename where id > 134277; очень даже используются.
Попытаюсь высказать свое некоторое видиние проблемы.
На мой взгляд релляционная база данных безусловно нужна!
Почему?
Потому что в поисковой системе безусловно будут и другие компоненты кроме поискового индекса. В зависимости от области применения такой системы, разной будет и сложность таких компонентов.Все реализовывать с помощью собственноручно сделанных способов долговременного хранения информации по крайней мере не разумно.А насчет накладных рассходов, то они по моим иследованиям достаточно малы(в подавляющем большинстве баз данных есть механизмы прекомпиляции запросов к выше преведенному примеру).
Какую БД выбрать? Я остановился на MySQL. Я сравнивал его и с ораклом и с постгрессом и с файрбердом. Почему? Он мне показался наиболее управляемым, простым и быстрым. В случае с ораклом, я столкнулся с ситуациями когда у меня что то где то начинало очень медленно работать, и что бы выяснить причину уходило много времени.
В конечном итоге я пришел к схеме, в которой документы, и различные их атрибуты(источник, язык) находились в базе данных, а поисковый индекс был сделан в виде инвертированного файла с использованием BerkeleyDB.
Имелось ввиду, что в результате качественной реализации связи вроде "вождение" -> "серпуховский район" могут быть отфильтрованы как незначительные.
О твоем последним на тот момент посте.
Ну эти погрешности могут варьироваться от реализации к реализации. Не секрет что есть хорошие продукты а есть плохие.
Ну ладно. Не буду спорить о терминологии. А на счет омонимии, то я пока не ставил себе задачу бороться с этим явлением. Я иследую другие области. К тому же моя система работает с новостями, где пользователю предположительно интересны конкретные персоналии, организации и события, и погрешность от омонимии не так уж и велика, как скажем в случае работы с художественными текстами.
Вообще насколько я понимаю та функциональность над которой я работаю выходит за рамки функциональности класических поисковых серверов А что по твоему такое семантическая сеть?
Ну вот в своем проекте я видимо использовал то что вы называете семантические сети. То есть сем сеть у меня -- это граф понятий и связей между ними. Он хранится в базе данных. Строится автоматически. Простейший случай -- это статистические связи -- то есть если два слова встречаются в одном предложении то между ними существует связь, силу которой я измеряю дополнительно. В более сложном я применяю синтаксические характеристики. То есть понятием может быть именная группа. Примером связи может быть например связь между подлежащим и дополнением как между субьектом и обьектом действия в с действием в виде сказуемого. У меня для этого реализован специальный язык синтаксических правил.Дальше хочу прийти к фреймовой модели и реалзиовать фактографический поиск. То есть например пользователь вводит в поле субьекта действия слово кучма, в поле действия слово подписал в поле обьекта знак вопроса, и получает новости в которых кучма что то подписал за определенный период. Думаю такое реализовать вполне возможно.
