21.3. Generation of application-oriented database systems

The idea is very simple: it will never be possible to create a universal database management system that is sufficient and not redundant for use in any application. For example, if you look at the use of universal commercial DBMS (for example, Oracle or Informix) in Russian reality, you can easily see that in at least 90% of cases, no more than 30% of the system’s capabilities are used. However, the application bears the brunt of the DBMS supporting it, designed for use in the most common cases.

Therefore, it is very tempting to produce unfinished universal DBMSs, but rather something like compiler compilers (compiler compilers), allowing you to build a database system oriented to a specific application (or application class). Consider simple examples:

In ticket reservation systems, requests are usually so simple (for example, “issue another seat for SU 645 flight”) that it makes little sense to produce large-scale query optimization. On the other hand, the information stored in the database is so critical (which of us did not face the problem of having two or more tickets for one seat?) That guaranteed synchronization of database updates and its recovery after any failure is particularly important.

On the other hand, in statistical systems, requests can be arbitrarily complex (for example, “give out the number of male idlers living in Russia and having at least three registered children”), which necessitates the use of advanced query optimization tools. On the other hand, since we are talking about statistics, it does not require the support of strict transaction serialization and accurate recovery of the database after failures. (Since this is statistical information, the loss of a few of its units is usually not significant.)

Therefore, it is desirable to be able to generate a database system, the capabilities (and corresponding overhead costs) of which are sufficiently relevant to the needs of the application. Today, there are no such "generation" systems on the commercial market (for example, when choosing an Oracle server, you cannot refuse any of its properties unnecessary for your application or require some additional properties). However, there are at least two experimental prototypes - Genesis and Exodus.

Both of these generation systems are based primarily on the principles of modularity and exact adherence to the installed interfaces. In essence, the systems consist of a minimal kernel (a developed file system in the case of Exodus) and a technological mechanism for programming additional modules. In the Exodus project, this mechanism is based on the E programming system, which is a simple C ++ extension that supports stable data storage in external memory. Instead of a ready-made DBMS, a set of "semi-finished products" is provided with consistent interfaces from which you can generate a system that best meets the needs of the application.