Minimal IT logo and link to home page
Research, training, consultancy and software to reduce IT costs
Home | About | Newsletter | Contact
Previous | Next Printer friendly
24 June 2014

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.

Node, Member, Node Type and Member Type

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:

Value Scale Target
Member 1 value Member 1 scale Member 1 target
Member 2 value Member 2 scale Member 2 target
... etc ... etc ... etc

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:

United Kingdom

The cost and currency of the printer I just bought:


Latest results from the lottery:


Prioritised emergency call-out list:

Mr Bean

Grades and scores for assessing swimming pool water quality:

Scale Target
0 Brown and smelly
25 Green and cloudy
60 Mostly clear, some debris
100 Clear and sparkling

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.

Next: Node types and member types


To subscribe to the newlsetter, simply send an email to
Privacy policy

Subscribe to RSS feed

Latest newsletter:
Magical metadata

We use the term "metadata-driven" to describe IT solutions in which functionality is defined in data. Taking this to the extreme can provide unparalleled levels of speed, simplicity and versatility.
Read full newsletter

System governance

System governance helps you implement high-quality systems, manage existing systems proactively, and improve failing systems.

Try it for free!

Find out more