Skip to main content

Storage

Introduction

Cognibase implements a very modular and flexible architecture as Data Access Layer for the Code-First approach. The Object Server is able to use different technologies as Database, or generally Data Storage, and this is one of its biggest advantage. In this way it can be considered a real-time layer on top of any Database. Currently, the following technologies are implemented.

SQL Adapters

A Code-First ORM has been implemented to support SQL Databases and specific adapters have been implemented for each of the following:

  • MS SQL Server & Azure SQL
  • Oracle SQL Server
  • PostgreSQL Server
  • SQLite

Any other SQL DB technology can be easily supported.

Data Representation

The SQL representation of DataItems is quite simple but extremely flexible.

  • For each DataItem type there is one table for the scalar fields, named as the type, and one table for the reference fields that includes both single and list reference fields, having the suffix "REF".
  • There is one special table, named SYS_RefBy_For_XxDomain (per Domain) for storing the reverse reference for each DataItem.
  • There is one special table, named SYS_AutoValues_For_XxDomain (per Domain) for storing the auto-increment values.

There is also flexibility on where the tables of the DataItems reside. For example in MS SQL Server someone has the option to use one MS SQL Database per Domain, or use just a single Database for all Domains.

Binary Files Adapter

The Binary Files adapter stores the DataItems in files. The data fields are serialized in one binary file per Entity instance.

Runtime Adapter

The runtime adapter is an adapter that stores the DataItems only in-memory.

Future Directions

We plan Cognibase to become a universal technology that will not depend on specific storage technology, but the users will be able to use any system easily. So, we plan to support multiple database systems of different types, like SQL, NoSQL (MongoDB, Cassandra), Graph, Multi-Modal (Cosmos), etc, as well as single files like JSON and XML.

In addition to multiple data stores, custom object-relational and object-document mapping is under investigation, so that there is the flexibility to optimize the underlying data representation based on the specific technology.

Finally, we plan to have easy support for location, time-series, JSON and other data types.