* Additional .gitignore entries * Merge a bunch of small articles about system tables into single one * Merge a bunch of small articles about formats into single one * Adapt table with formats to English docs too * Add SPb meetup link to main page * Move Utilities out of top level of docs (the location is probably not yet final) + translate couple articles * Merge MacOS.md into build_osx.md * Move Data types higher in ToC * Publish changelog on website alongside documentation * Few fixes for en/table_engines/file.md * Use smaller header sizes in changelogs * Group up table engines inside ToC * Move table engines out of top level too * Specificy in ToC that query language is SQL based. Thats a bit excessive, but catches eye. * Move stuff that is part of query language into respective folder * Move table functions lower in ToC * Lost redirects.txt update * Do not rely on comments in yaml + fix few ru titles * Extract major parts of queries.md into separate articles * queries.md has been supposed to be removed * Fix weird translation * Fix a bunch of links * There is only table of contents left * "Query language" is actually part of SQL abbreviation * Change filename in README.md too * fix mistype * s/formats\/interfaces/interfaces\/formats/g * Remove extra clarification from header as it was too verbose, probably making it a bit more confusing * Empty article was supposed to be hidden * At least change incorrect title * Move special links to the bottom of nav and slightly highlight them * Skip hidden pages in bottom navigation too * Make front page of documentation to be part of Introduction * Make tables in introduction somewhat readable + move abbreviation definitions earlier * Some introduction text refactoring * Some docs introduction refactoring * Use admonitions instead of divs * Additional .gitignore * Treat .gif as images too * Clarify ToC item
3.4 KiB
Dictionary key and fields
The <structure>
clause describes the dictionary key and fields available for queries.
Overall structure:
<dictionary>
<structure>
<id>
<name>Id</name>
</id>
<attribute>
<!-- Attribute parameters -->
</attribute>
...
</structure>
</dictionary>
Columns are described in the structure:
<id>
- key column.<attribute>
- data column. There can be a large number of columns.
Key
ClickHouse supports the following types of keys:
- Numeric key. UInt64. Defined in the tag
<id>
. - Composite key. Set of values of different types. Defined in the tag
<key>
.
A structure can contain either <id>
or <key>
.
!!! warning The key doesn't need to be defined separately in attributes.
Numeric key
Format: UInt64
.
Configuration example:
<id>
<name>Id</name>
</id>
Configuration fields:
- name – The name of the column with keys.
Composite key
The key can be a tuple
from any types of fields. The layout in this case must be complex_key_hashed
or complex_key_cache
.
!!! tip A composite key can consist of a single element. This makes it possible to use a string as the key, for instance.
The key structure is set in the element <key>
. Key fields are specified in the same format as the dictionary attributes. Example:
<structure>
<key>
<attribute>
<name>field1</name>
<type>String</type>
</attribute>
<attribute>
<name>field2</name>
<type>UInt32</type>
</attribute>
...
</key>
...
For a query to the dictGet*
function, a tuple is passed as the key. Example: dictGetString('dict_name', 'attr_name', tuple('string for field1', num_for_field2))
.
Attributes
Configuration example:
<structure>
...
<attribute>
<name>Name</name>
<type>Type</type>
<null_value></null_value>
<expression>rand64()</expression>
<hierarchical>true</hierarchical>
<injective>true</injective>
<is_object_id>true</is_object_id>
</attribute>
</structure>
Configuration fields:
name
– The column name.type
– The column type. Sets the method for interpreting data in the source. For example, for MySQL, the field might beTEXT
,VARCHAR
, orBLOB
in the source table, but it can be uploaded asString
.null_value
– The default value for a non-existing element. In the example, it is an empty string.expression
– The attribute can be an expression. The tag is not required.hierarchical
– Hierarchical support. Mirrored to the parent identifier. By default,false
.injective
– Whether theid -> attribute
image is injective. Iftrue
, then you can optimize theGROUP BY
clause. By default,false
.is_object_id
– Whether the query is executed for a MongoDB document byObjectID
.