Technical angle

Our ultimate goal is to provide access to the data via a thin app, as simple as possible. With other words: as cheap as possible to implement, or perhaps even generate it via a wizard, no coding needed.

When a user wants to access information via a traditional application with a relational database backend, it does two things in real time:

  1. Filters records

  2. Aggregates data

The data always have to be aggregated for human consumption. The only question is when we do this:

  1. In real time - when the user queries the data, OR

  2. In advance - so we store the data aggregated

Aggregated data is usually redundant, and a data creator application can't afford this. The relational data model is efficient because it does not store data redundantly. However, on-demand data aggregation can be very complex and resource-intensive.

Can we persist the data in an aggregated form, so the application can be simplified and only needs to deal with record filtering? The relational model falls short on this. It can do aggregation partly, but not entirely. The hierarchical model is a better choice.