An alternative to the relational modelThis 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 modelThe index cardsThe main storage entity in Storga is the form. A form is very similar to a paper form. For example, a card can contain an invoice. 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. Mechanics: A model by propagation of changesFirst 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. Then, with Storga, reports permanently store their content. Comparative analysisThe 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. 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. Reducing complexityWith 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 migrationAgain, 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 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. 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. 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. ConclusionThe Storga data model has two major advantages over the relational model:
|