0a4a5b36cc
* 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
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> .
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.
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, orBLOBin 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 -> attributeimage is injective. Iftrue, then you can optimize theGROUP BYclause. By default,false.is_object_id– Whether the query is executed for a MongoDB document byObjectID.