Руководство по созданию эффективных запросов

 
Поиск
Все, что обсуждалось в предыдущих главах, применимо к структурирован-
ным данным, и все рассмотренные до сих пор запросы следуют булевой 
логике. Строка либо нужна для вычисления результата, либо нет; вычислен-
ная строка либо принадлежит результату, либо нет. Третьего не дано. SQL – 
мощный язык для структурированных данных, который хорошо подходит 
для такого рода анализа.
В этом разделе мы рассматриваем неструктурированные данные. Самый 
простой пример неструктурированных данных – текст, написанный на ес-
тественном языке. Такие тексты обычно называют 
документами
. В отличие 
от структурированных данных, поиск документов всегда неточен, потому что 
нас обычно интересует смысл, а он не выражен точно в содержании докумен-
та. Зато критерии должны быть точно выражены в запросе. Добро пожаловать 
в мир неопределенности!
Существует несколько различных моделей поиска документов; та, что реа-
лизована в PostgreSQL, называется булевой моделью. Обратите внимание, 
что современные поисковые системы в интернете используют более сложные 
модели.
В булевой модели поиска документ рассматривается как список 
термов
. 
Каждый терм обычно соответствует слову из документа, преобразованному 
с помощью определенных лингвистических средств. Такое преобразование 

---

Многомерный и пространственный поиск 

261
необходимо для повышения качества поиска. Например, мы ожидаем, что 
слова «слово» и «слова» должны соответствовать одному и тому же терму. 
Преобразования нетривиальны: «лечь» и «лягу» – это формы одного и того 
же слова, но «лягушка» – совсем другое. И это не просто морфологические 
преобразования: значение зависит от контекста.
Например, слова «хост» и «компьютер» имеют одинаковое значение в до-
кументе, описывающем сетевые протоколы, но их смысл различается, когда 
речь идет об организации конференции.
В PostgreSQL лингвистические правила, определяющие преобразования, 
инкапсулируются в 
конфигурацию
. Доступно несколько предопределенных 
конфигураций для разных языков, и могут быть определены дополнитель-
ные. Одна из предопределенных конфигураций не зависит от языка и огра-
ничивается простыми преобразованиями.
Результат лингвистической обработки представлен как значение типа
tsvector
. Значения 
tsvector
не относятся к какому-либо языку или даже 
к текс ту и представляют собой списки термов. Значение типа 
tsvector
можно 
построить из любого списка значений.
Почему текстовый поиск называется 
полнотекстовым
поиском
? Во вре-
мена средневековья (1970-е годы), когда емкость жестких дисков была не-
большой, списки термов составлялись только из заголовков или аннотаций. 
Таким образом, «полный текст» означает, что все слова в документе рассмат-
риваются как источник термов.
Похожим образом запрос для поиска документа представлен как значение 
типа 
tsquery
. Эти текстовые значения могут содержать слова и логические 
связки «и», «или» и «не». Простой запрос состоит только из слов.
Документ соответствует такому запросу, если все термы в запросе при-
сутствуют в 
tsvector
, соответствующем документу.
Оператор сопоставления 
@@
возвращает истину, если документ удовлет-
воряет запросу, и ложь в противном случае. Его можно использовать в пред-
ложении 
WHERE
команды 
SELECT
или в любом другом месте, где ожидается 
логическое выражение.
Булев поиск дает определенные результаты: документ либо соответствует 
запросу, либо нет. Но поиск при этом неточный? Да, так и есть. Часть ин-
формации теряется при преобразовании документа в 
tsvector
, а часть – при 
преобразовании запроса в 
tsquery
.
Полнотекстовый поиск работает и без индексов, но PostgreSQL предостав-
ляет специальные типы индексов, которые могут его ускорить. Мы обсудим 
эти типы индексов далее в данной главе.