An alternative to the relational model

This document sets out the main lines of the data organization model in Storga, as well as the practical consequences that flow from it.

Description of the model

The index cards

The main storage entity in Storga is the form. A form is very similar to a paper form.
It includes simple input fields, tables (under tables), and possibly one or more programs.
The programs allow you to define calculation rules between the different elements of the form.

For example, a card can contain an invoice.
We will have as a simple input field the invoice number, the date, the recipient's contact details, etc.
We will also have a sub table with a list of items, and for each item the name, the unit price, the quantity.
Finally, we will have a total field and a program which calculates the total from the sub-table of articles.

Unlike a spreadsheet, the program is not a formula associated with each field, but a global program for the record, which facilitates re-reading.

The reports

A report is an array obtained by specifying the type of records to collect, the area or areas of the tree structure where to look for them, a possible filtering formula to specify more precisely which records must be collected, the fields to be collected, possibly certain fields to be calculated at the time of collection, a formula allowing to specify in which order to display the result, etc.

The reports can also contain at the top of the fields used to configure the display.
In the previous example, we could have a report that lists all the invoices, with fields allowing to specify the desired period, to filter the estimates corresponding to a given recipient, etc.
In fact, from the user's point of view, Storga states can be seen as the result of a query in the relational model.
On the other hand, we will now see that from the point of view of computational mechanics, things are very different.

Mechanics: A model by propagation of changes

First of all, a Storga form contains both the data and the layout, and the program or programs that define the automations. With Storga, a form is complete, as in the case of a paper document; it does not need an external application to display or edit it.
In contrast, in the relational model, the data constituting a record is 'submerged' into tables, which contain data from multiple records. To edit a record, we need an application that will extract the data, add the layout elements and, if the user modifies a field, apply the change in the right row of the right table.

Then, with Storga, reports permanently store their content.
In contrast, with the relational model, a report is produced on each request, by a program which extracts the data from the various tables.
This induces a fundamental difference: with Storga, when you modify a form, the change is immediately propagated to the different states that use this file.
Conversely, in the relational model (except for exceptions called 'triggers'), when we modify a form, we do nothing at the level of the states which will be rebuilt entirely on demand.This results in very different functional constraints: with Storga, the browsing of the forms can be slow, since the reports do not need to be browsed again on each display.
On the other hand, we need a powerful mechanism to ensure that the changes on the forms are correctly propagated to the reports.

Comparative analysis

The real challenge for a database model: n-n relationships

This is where non-relational databases usually fall apart. This is what justifies the historical success of the relational model, which has ousted all others, and which is a reflection of objective technical superiority, as opposed to the many cases where success is the result of non-technical parameters.

To understand what an n-n relation is, let's take the case of invoices again.
We make invoice sheets.
We want to be able to access the item sheets which each list for an item all the sales (therefore the lines of the invoices that concerned this item).

With a non-relational database, building an item form requires going through all the invoices again, and therefore collapses the system very quickly.

The beauty of the relational model is that in order to be able to efficiently obtain the item records, it suffices to add (which the system generally does on its own) a secondary index on the table.

With Storga, we will create a report of all the items ordered in all the invoices, then we will define item records, and the program for each item record will fill it in by browsing the report.
The beauty of Storga is that this mechanism is also transparent: when you modify an invoice, the status will be automatically updated, and the item records concerned too.

Reducing complexity

With Storga, the data displayed on the screen is in direct correspondence with what is stored. This is the result of what has been described above: a Storga file contains both data and presentation information, therefore does not depend on an external program, and a report stores what it displays.

Therefore, if a user wants to automate what he can do by hand, in a few clicks he will be able to determine the name of the fields he wants to use, the code of the form from which he wants to extract data, etc.

Conversely, with the relational model, when you see a field on the screen, to be able to use it in a new automation, you have to find the program that displays the said form, understand it, and possibly also understand the sub programs which were used to calculate the said field.

Thus, with Storga, the dialogue between a user and a developer is simple and immediate since they speak of the same thing when the user shows on the screen and the developer notes the references of the fields. While in the relational model, there is a lot of transposition work: the user continues to climb to the screen, but the developer must translate this by diving into the relational model, or into calculations to be carried out to reconstruct the data seen .

As a corollary, with Storga, a user trained in Storga can easily adapt an existing system, because what he sees is the basis for programming new automations, or modifying the structure. With the relational model, you have to understand the architecture of the application and the underlying relational model, neither of which is visible to the user, and can be very complex even if ultimately l automation or the desired modification are minor.

Data migration

Again, with Storga, a record contains both the data and the structure of the record to display it. In fact, when we want to develop an activity, very often we modify the structure of the files that will be created in the future, without modifying the existing files.
This makes the changes much simpler, but it is hardly practical with the relational model where in practice it is necessary to organize the adaptation of all the existing data.

This is even more true in the case of the combination of two sites. With Storga, we will be able to gradually develop the forms used on both sides, without having to carry out an impossible conversion of the existing one. In the end, we will have old forms, new ones, exactly as with a paper organization, and that will not pose a major problem.
With the relational model, this would generally lead to an explosion of complexity at the code level.

The functional level: events versus transactions

Finally, let's take a step back by describing the implicit activity description model for each data storage model.

With the relational model (storage), the natural modeling of activity is the storage of the current position. This is both the result of a very powerful function and a limitation of the relational model. The very powerful function is the notion of transaction which allows for example to debit an account and credit another in an atomic way, that is to say that either nothing or everything will be done, but not half. This helps to ensure the consistency of the current position.

With the Storga model (storage), the natural modeling of the activity is the storage of all the forms where each form is the direct report of an event. What makes this approach natural in Storga is that if we need to define hundreds of types of forms to directly model the hundreds of types of possible operations over time, this does not pose any particular problem. , whereas with the relational model, it would be a nightmare to have to maintain the hundreds of programs to be able to edit the hundreds of types of forms.
Conversely, Storga does not need a transaction, because the all-or-nothing debit / credit will be obtained by the presence or absence of a fund transaction form.

In other words, it is because realizing and especially maintaining the programs which make it possible to edit the different types of forms is very expensive that with the relational model, we tend, to limit the quantity of programs to write, to seek to code the current position rather than the entire transaction history.
The consequence is that with the relational model, there are many more errors, not in calculation but in transposition by the operator of the real in the database. This is all the more true in complicated cases, that is to say the few cases that go wrong. With the natural modeling corresponding to Storga, when a customer calls to report a problem, all one has to do is read and verify with him the sequence of operations, where each operation has been recorded as a 'a Storga file. With the relational model, we will have to take the list of operations by retrieving the data on the right and on the left (emails, scanned forms, etc.), deduce the correct current position, compare it to the current position in the system, and save a new operation to compensate for the error, a bit like in accounting where erroneous entries are not corrected, but where they are compensated by a corrective entry.

Conclusion

The Storga data model has two major advantages over the relational model: