8623cb232c
* CLICKHOUSE-4063: less manual html @ index.md * CLICKHOUSE-4063: recommend markdown="1" in README.md * CLICKHOUSE-4003: manually purge custom.css for now * CLICKHOUSE-4064: expand <details> before any print (including to pdf) * CLICKHOUSE-3927: rearrange interfaces/formats.md a bit * CLICKHOUSE-3306: add few http headers * Remove copy-paste introduced in #3392 * Hopefully better chinese fonts #3392 * get rid of tabs @ custom.css * Apply comments and patch from #3384 * Add jdbc.md to ToC and some translation, though it still looks badly incomplete * minor punctuation * Add some backlinks to official website from mirrors that just blindly take markdown sources * Do not make fonts extra light * find . -name '*.md' -type f | xargs -I{} perl -pi -e 's//g' {} * find . -name '*.md' -type f | xargs -I{} perl -pi -e 's/ sql/g' {} * Remove outdated stuff from roadmap.md * Not so light font on front page too * Refactor Chinese formats.md to match recent changes in other languages
3.5 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, 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.