Structuring custom data
This page provides some guidelines for when you collect custom data in GoToManage.
Never name nodes after aspects of the data, such as after software applications, response codes, and so on. To figure out if you are using data to name tree nodes, ask the following questions:
- Do you know every name that could possibly be used?
If not, then you are probably using data and should use a different name. - Is the name an aspect of the ontology or an aspect of the data?
If it is an aspect of the data, then use a different name.
Example of nodes named after data
In this example of what not to do, the name of each node is based on an HTTP response code, and the value is the number of responses using that code:
apache_response_codes =>
res_200 => 14
hits => 0
res_304 => 67
res_500 => 3
res_302 => 1
res_404 => 2
res_422 => 1
The use of data to name nodes results in a number of problems:
- Many types of queries become hard, if not impossible, to write. In the example of nodes named after data above, you cannot write a query that generates a row for each response type, or create a pie chart of the response codes.
- It is difficult to use indexes. Indexes are specified for a path, but if the path depends on an aspect of the data, then that aspect cannot be indexed. In fact, the aspect you are most likely to use as a name is often the one you want most to index.
- The ontology changes when new data is added, which pollutes the ontology. It is advantageous to keep the ontology as small as possible. Features such as adding descriptions to nodes becomes impractical if the ontology is constantly changing.
Alternative example
Instead, structure the tree with a sub-tree for each type of response code. For example:
apache_response_codes =>
hits => 0
response =>
code => 200
response_count => 14
response =>
code => 304
response_count => 67
response =>
code => 500
response_count => 3
response =>
code => 302
response_count => 1
