THE BASIS

Simple transactional database (STDB) is based on transactions. Transactions are always transmitted entirely; if not, they are rejected. So, we can assure the database integrity in blocks of transactions, because all of them must be "commited". Originally, STDB works into memory all the time until we call to "Commit", and entries are automatically ordered by name. When executing a "commit", we order the database to save all movements since the last transaction to an intermediate file, called the LOG file.

The LOG file is designed as an intermediate buffer to store transactions until we call to Reorganize (or STDB calls it when necessary). This function rebuilds the entire database, updated with all these movements stored at the LOG file. Reorganize always does backup of the last known coherent DB file, so we can always restore it if problems occur.

If something goes wrong, there's always a copy of the LOG file and the last correct DB file. However, we cannot assure ALL your data will be saved. Only those movements passed into transactions have some warranty, and if the LOG file crashes, only full transactions will be saved. The idea is based on STDB ability to maintain our database integrity: maybe not all movements are stored, but those into the database are correct for sure.

The user may find much more detailed information into the Documentation section. There you will find the reference to this library and all his functions.

APPLICATIONS - PROS AND CONS

STDB is initially designed to manage pairs key/value, so you could apply this engine in a vast range of solutions. However, due it's programmed in C++, the user could easily adapt the software to many other applications. Imagine some kind of embedded device transmitting data like Position-Temperature or Position-Pressure. This kind of data is elligible to be monitored and managed through a STDB database.

The most illustrative example, though, is the bank transaction. Imagine there is a Name Account and a Value representing the money associated to this account. If the operation was not transactional, it could be possible to pass an Account and loss the corresponding value. Problem. We must be sure data has been transmitted entirely, because it doesn't have sense separately.

The cons: not always is possible to maintain the coherence, due to hardware and operating system limitations. Furthermore, this library is not designed as a high secure transactional database engine (sure it exists and is very very expensive). STDB is just a Simple transactional database, aimed to fit simple applications, such on embedded systems, including an acceptable level of redundancy.