Member storage model

By Andrew Clifford

Metrici has a versatile storage model based more on pragmatism and experience than on data theory.

In How Metrici is structured we covered the internal structure of Metrici. Over the next few weeks we are going to look at this in more detail and cover how to define new types of data.

To recap, in Metrici:

• Everything is a node.
• Nodes' data is stored in members.
• Each node is defined by another node, its node type.
• Each member is defined by a node, the member type.
• Node types list the member types that should be used for a node.

This week we are going to look at the storage of data in members.

Each member can hold three pieces of data:

• A piece of text, known as the "value".
• A number, known as the "scale".
• A link to a node, known as the "target".

Members with the same member type can repeat. The member type defines a minimum and maximum cardinality (number of repeats), though in 99.9% of cases we either set a maximum cardinality of 1 (no repeat) or unlimited. Members are inherently ordered.

You can therefore think of the members with the same member type as a table:

By varying which of the value, scale and target are used, and whether the members repeat, this structure can be used to hold pretty much any data. Here are some examples:

My name:

The country I live in:

The cost and currency of the printer I just bought:

Latest results from the lottery:

Prioritised emergency call-out list:

Grades and scores for assessing swimming pool water quality:

Notice how "things" like country, currency, superhero and water quality are all implemented as links to other nodes, not as names or references as they might be in a conventional database.

There is no theoretical basis for this storage model. We came up with the model by analysing the data structures within version 1 of Metrici (when it was just an assessment tool), and trying to come up with a model that would fit all of our data needs as efficiently as possible. Our subsequent experience has shown that this is a very versatile way of storing data, and copes easily with 99% of data requirements. It works well for structured data in databases and for less structured web content. It achieves some of the "attribute on link" capabilities of, for example, the associative model of data, without a significant increase in complexity. In comparison to a conventional triple store, it removes the need for a lot of link nodes that just exist to define the relationship between other nodes. It maps easily onto a conventional database.

Armed with this knowledge of the member storage model, next week we will cover how to define member types and node types to store any type of data.

Subscription