Multi generational engine.

    Probably, this feature would not be understood without starting with a brief explanation of a multi generational engine. For those people who have played with Object Oriented databases and object relational databases, one typical feature is having several versions of the same object at the same time.

In a classic relational database, you have one and only one version of an object that every user sees. There may be a second, "unofficial" version of an object at the time a user is changing the original object but the changes are not confirmed yet. For the sake of simplicity in this explanation, let's understand an object as one tuple, namely, one record or row, that's also called "a relational entity". I agree you can denominate a relation (a complete table) or stored procedure a relational object, but I need to make an analogy with object oriented databases, so I will stick with a tuple for now.

In an object oriented database, commonly referred as OODBMS, there may be several versions of the same object. Each consistent collection of related objects' versions is called "a configuration", so you may have several configuration or snapshots of the database at the same time. The same version of an object can be part of more than one configuration if it has not changed. By walking configurations, you can know the evolution of the objects. Going further, the metadata itself (IE, the structure and relationships of the objects) can have several versions at the same time in some products. Sometimes, there's only one global representation for the data in both the engine and the applications, like in ObjectStore (see for more details), so the speed is great (perhaps unreachable by a relational engine) but a change in the database schema has a direct impact in the application and vice versa.

Interbase is a compromise or tradeoff product. You have a classic relational database, you have SQL, your data in the engine has a rigorous separation from the data in the client application (the internal representation of the data may differ), you have stored procedures and the most widely set of commands and features a RDBMS should expose and you can connect with any client, provided that you have the proper ODBC or other drivers or make a connection using the raw API. But Interbase may have several versions of the same object (in this case, a tuple). However, contrarily to an ODBMS, these versions are for internal use of the engine itself and not for you: you cannot walk the different version at your will. You always see the most confirmed (committed) version of a tuple or can choose to wait for it to become available. What's the value then, you may ask. The engine uses this mechanism to its own advantage, see the next feature, non blocking engine.

This page was last updated on 2000-05-26 04:28:46