MarkLogic 9 Product DocumentationDatabase Field Configuration Help
A
Field
specifies a named object that has its own index term lists and can
be searched with the query constructor
cts:field-word-query.
Use this configuration to specify if the field is built using
paths or from the root element of a document. In most cases,
paths are the preferred way to build a field. You can specify
multiple paths for a field, and each path can have a weight to
boost or lower relevance scores for searches with matches in that
path.
To add or remove index options to the field, you can check or
uncheck index options you want to add or remove.
You can create field range indexes, define word lexicons, and
specify overrides for how to tokenize content using the Database
Fields Configuration page.
You can also specify elements to include or exclude from the field,
specify query weights that apply to specific elements
for relevance calculations, and constrain which
elements are included or excluded by a specified attribute
value.
The bold type on any index setting name indicates that the index setting is inherited from the database configuration.
The following are the configuration options:
- field name specifies the name of the field.
-
include
document root specifies if this field should begin
including elements at the root element for each
document (unless that element is explicitly excluded). This
is set to
falseby default, which means you must explicitly include some elements for the field to have any content. A field that has include document root specification cannot have field paths. -
field path specifies root of an instance of the field in a document. A field can have one or more field paths. Each field path locates entry points to one or more field instances in the document. Different field paths may point to different kinds of instances in the document. A field can have either field paths or include-root specification. Word query can have only include-root specification.
-
stemmed
searches specifies whether index terms should be included
in the database files to support stemming. When set to
basic, basic stemming is enabled, and the shortest stem of each word is indexed. When set toadvanced, all stems of each word are indexed. When set todecompounding, all stems are indexed, and smaller component words of large compound words are also indexed. Each successive level of stemming improves recall of word searches, but also causes slower document loads and larger database files. - word searches specifies whether index terms should be included in the database files to support fast word searches. When this parameter is true, word searches are faster, but document loading is slower and the database files are larger.
-
field value
searches specifies whether index data is included which
speeds up the performance of field value queries that use the
cts:field-value-queryfunction. Turn this index off if you are not interested in field value queries and if you want to conserve disk space and decrease loading time. -
field value
positions specifies whether index data is included which
speeds up the performance of proximity queries that use the
cts:field-value-queryfunction. Turn this index off if you are not interested in proximity queries and if you want to conserve disk space and decrease loading time. - fast phrase searches specifies whether index terms should be included in the database files to support fast phrase searches. When this parameter is true, phrase searches are faster, but document loading is slower and the database files are larger.
- fast case sensitive searches specifies whether index terms should be included in the database files to support fast case-sensitive searches. When this parameter is true, case-sensitive searches are faster, but document loading is slower and the database files are larger.
- fast diacritic sensitive searches specifies whether index terms should be included in the database files to support fast diacritic-sensitive searches. When this parameter is true, diacritic-sensitive searches are faster, but document loading is slower and the database files are larger.
- trailing wildcard searches specifies whether indexes should be created to enable wildcard searches where the search pattern contains one or more consecutive non-wildcard characters at the beginning of the word, with the wildcard at the end of the word (for example, abc*). When this parameter is true, character searches are faster, but document loading is slower and the database files are larger.
-
trailing wildcard
word positions specifies whether index data should be
included in the database files to enable proximity searches
(
cts:near-query) within trailing wildcard queries. You must also enable trailing wildcard searches in order to perform trailing wildcard position searches. When this parameter is true, positional searches are possible within a trailing wildcard query, but document loading is slower and the database files are larger. - three character searches specifies whether indexes should be created to enable wildcard searches where the search pattern contains three or more consecutive non-wildcard characters (for example, abc*). When combined with a codepoint word lexicon, speeds the performance of any wildcard search (including searches with fewer than three consecutive non-wildcard characters). MarkLogic recommends combining the three character search index with a codepoint collation word lexicon. When this parameter is true, character searches are faster, but document loading is slower and the database files are larger.
-
three character
word positions specifies whether index data should be
included in the database files to enable proximity searches
(
cts:near-query) within wildcard queries. You must also enable three character searches in order to perform wildcard position searches. When this parameter is true, positional searches are possible within a wildcard query, but document loading is slower and the database files are larger. -
two character
searches specifies whether indexes should be created to
enable wildcard searches where the search pattern contains two
consecutive non-wildcard character (for example,
ab*). This index is not needed if you have three character searches and a word lexicon. -
one character
searches specifies whether indexes should be created to
enable wildcard searches where the search pattern contains a single
non-wildcard character (for example,
a*). This index is not needed if you have three character searches and a word lexicon. -
word
lexicons specifies the word lexicons to keep or to add for
this configuration. You can have multiple word lexicons in a
database or a field,
each with different collations. To add a new lexicon, enter the
collation for the lexicon in the
[add]box (for example,http://marklogic.com/collation/for the UCA Root Collation, which is a sensible collation for many applications). To remove a lexicon, uncheck the[keep]box for the lexicon you want to remove. The specified collation is used to order the words in the lexicon. Each lexicon contains a list of unique words in the database or field, where uniqueness is determined based on the collation chosen. Typically, the specified collation is case-sensitive and diacritic-sensitive so that there are different entries forFordandford. Also speeds up wildcard searches. Works in combination with any other available wildcard indexes to improve search index resolution and performance. When used in conjunction with the three character search index, improves wildcard index resolution and speeds up wildcard searches. - included elements are elements that should be indexed by this field (i.e. elements that will be searched when searching this field).
- excluded elements are elements that should not be indexed by this field (i.e. elements that will not be searched when searching this field).