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

Для выполнения поиска в Digital Q.DataBase, документ обычно является текстовым полем в строке таблицы базы данных или совокупностью (конкатенацией) таких полей, которые могут быть распределены по нескольким таблицам или формироваться динамически. Иными словами, документ для индексирования может быть составлен из различных фрагментов и не существовать в базе данных в виде единого целого. Например:

SELECT title || ' ' ||  author || ' ' ||  abstract || ' ' || body AS document
FROM messages
WHERE mid = 12;

SELECT m.title || ' ' || m.author || ' ' || m.abstract || ' ' || d.body AS document
FROM messages m, docs d
WHERE m.mid = d.did AND m.mid = 12;

Другим вариантом является хранение документов в виде обычных текстовых файлов в файловой системе. В этом случае базу данных можно использовать для хранения индекса полнотекстового поиска и выполнения поисковых операций, а для получения документа из файловой системы использовать некоторый уникальный идентификатор. Однако извлечение файлов из внешних источников за пределами базы данных требует прав суперпользователя или поддержки специальных функций, поэтому данный подход обычно менее удобен, чем хранение всех данных внутри базы данных Digital Q.DataBase. Кроме того, хранение всех данных непосредственно в базе данных обеспечивает удобный доступ к метаданным документов для упрощения процессов индексирования и отображения.

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

Полнотекстовый поиск в Digital Q.DataBase основан на операторе соответствия @@, который возвращает значение true в том случае, если tsvector (документ) соответствует tsquery (запросу). Порядок указания типов данных при этом не имеет значения:

SELECT 'a fat cat sat on a mat and ate a fat rat'::tsvector @@ 'cat & rat'::tsquery;
 ?column?
----------
 t

SELECT 'fat & cow'::tsquery @@ 'a fat cat sat on a mat and ate a fat rat'::tsvector;
 ?column?
----------
 f

Как показывает приведенный выше пример, tsquery не является просто набором необработанных текстовых данных, равно как и tsvector . Объект tsquery содержит поисковые термы, которые должны представлять собой уже нормализованные лексемы; при этом допускается логическое комбинирование нескольких термов с помощью операторов AND, OR, NOT и FOLLOWED BY. (Подробные сведения о синтаксисе приведены в Раздел 2.5.11.2.) Существуют функции to_tsquery, plainto_tsquery, и phraseto_tsquery , которые позволяют преобразовать введенный пользователем текст в корректное значение tsquery, в первую очередь за счет нормализации входящих в текст слов. Аналогично, функция to_tsvector используется для синтаксического анализа и нормализации строки документа. Таким образом, на практике операция текстового поиска будет выглядеть следующим образом:

SELECT to_tsvector('fat cats ate fat rats') @@ to_tsquery('fat & rat');
 ?column?
----------
 t

Обратите внимание, что данное соответствие не было бы найдено, если бы запрос был записан в виде

SELECT 'fat cats ate fat rats'::tsvector @@ to_tsquery('fat & rat');
 ?column?
----------
 f

поскольку в этом случае нормализация слова rats произведена не будет. Элементами типа tsvector являются лексемы, которые предполагаются уже нормализованными, поэтому значение rats не соответствует значению rat.

Оператор @@ также поддерживает текстовые входные данные, что позволяет в простых случаях исключить явное приведение текстовой строки к типу tsvector или tsquery to be skipped in simple cases. Доступны следующие варианты:

tsvector @@ tsquery
tsquery  @@ tsvector
text @@ tsquery
text @@ text

Первые два варианта уже были рассмотрены ранее. Форма текстовые @@ tsquery эквивалентна выражению to_tsvector(x) @@ y. Данная форма текстовые @@ текстовые эквивалентна выражению to_tsvector(x) @@ plainto_tsquery(y).

В рамках tsquery, the & оператор (AND) определяет, что для успешного сопоставления в документе должны присутствовать оба его аргумента. Аналогично, | оператор (OR) указывает на то, что должен присутствовать хотя бы один из его аргументов, в то время как ! оператор (NOT) определяет, что его аргумент не должен содержаться в документе для успешного сопоставления. Например, запрос fat & ! rat соответствует документам, которые содержат fat но не содержат rat.

Поиск фраз возможен с помощью оператора <-> (FOLLOWED BY) tsquery , который обеспечивает совпадение только в том случае, если его аргументы расположены рядом и в заданном порядке. Например:

SELECT to_tsvector('fatal error') @@ to_tsquery('fatal <-> error');
 ?column?
----------
 t

SELECT to_tsvector('error is not fatal') @@ to_tsquery('fatal <-> error');
 ?column?
----------
 f

Существует более общая версия оператора FOLLOWED BY, имеющая следующий вид: <N>, где N — целое число, обозначающее разницу между позициями соответствующих лексем. <1> эквивалентно выражению <->, тогда как <2> допускает наличие ровно одной другой лексемы между искомыми словами и так далее. phraseto_tsquery Функция использует данный оператор для формирования запроса типа tsquery , который позволяет сопоставлять многословные фразы в тех случаях, когда некоторые слова являются стоп-словами. Например:

SELECT phraseto_tsquery('cats ate rats');
       phraseto_tsquery
-------------------------------
 'cat' <-> 'ate' <-> 'rat'

SELECT phraseto_tsquery('the cats ate the rats');
       phraseto_tsquery
-------------------------------
 'cat' <-> 'ate' <2> 'rat'

Частным случаем, который иногда оказывается полезным, является ситуация, когда <0> может использоваться для требования соответствия двух шаблонов одному и тому же слову.

Скобки могут применяться для управления вложенностью tsquery операторов. Без использования скобок | имеет самый низкий приоритет, затем &, затем <->, и ! самый высокий приоритет.

Стоит отметить, что операторы AND/OR/NOT имеют несколько иное значение, когда они находятся внутри аргументов оператора FOLLOWED BY, поскольку в контексте FOLLOWED BY важна точная позиция совпадения. Например, в обычном случае !x соответствует только тем документам, которые не содержат x в любом месте. Однако !x <-> y соответствует y если оно расположено не непосредственно после x; наличие x в другом месте документа не препятствует нахождению совпадения. Другим примером является то, что x & y обычно требует лишь того, чтобы x и y оба терма присутствовали в произвольном месте документа, в то время как (x & y) <-> z требует x и y обеспечения совпадения в той же позиции, непосредственно перед z. Таким образом, поведение данного запроса отличается от x <-> z & y <-> z, который будет соответствовать документу, содержащему две отдельные последовательности x z и y z. (В представленном виде данный запрос не имеет практического смысла, поскольку x и y не может привести к совпадению в той же позиции; однако в более сложных сценариях, таких как поиск по префиксу, запрос подобного формата может оказаться полезным.)

Все приведенные выше примеры относятся к простому текстовому поиску. Как было отмечено ранее, функциональность полнотекстового поиска предоставляет расширенные возможности: исключение определенных слов из процесса индексирования (стоп-слова), обработку синонимов, а также применение сложных алгоритмов синтаксического анализа (например, разбор текста не только по пробелам). Управление данными функциями осуществляется через конфигурации текстового поиска. Digital Q.DataBase система содержит наборы предопределенных конфигураций для многих языков; также предусмотрена возможность создания пользовательских конфигураций. (psqlинструмент \dF команда отображает все доступные конфигурации).

В процессе установки выбирается подходящая конфигурация, которая default_text_search_config записывается в качестве значения параметра в postgresql.conf. Если для всего кластера баз данных используется единая конфигурация текстового поиска, можно применять значение из postgresql.conf. Для использования различных конфигураций в масштабе кластера при сохранении единой конфигурации в пределах конкретной базы данных используйте команду ALTER DATABASE ... SET. В иных случаях параметр можно определить default_text_search_config индивидуально для каждой сессии.

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

Для упрощения процесса создания пользовательских конфигураций текстового поиска конфигурация формируется из более простых объектов базы данных. Digital Q.DataBaseсредства текстового поиска предоставляют четыре типа объектов базы данных, относящихся к конфигурации:

Парсеры и шаблоны текстового поиска строятся на основе низкоуровневых функций языка C; таким образом, разработка новых компонентов требует навыков программирования на языке C, а их установка в базу данных — прав суперпользователя. (Примеры дополнительных парсеров и шаблонов приведены в contrib/ дистрибутива СУБД.) Digital Q.DataBase Поскольку словари и конфигурации лишь параметризуют и связывают воедино базовые парсеры и шаблоны, для создания нового словаря или конфигурации не требуется специальных привилегий. Примеры создания пользовательских словарей и конфигураций приведены далее в текущей главе.