ObjectDatabase++

Traditionally databases have been designed with the relational model. This would separate data over several tables and use a common identifier to relate all the child records back to their parent. These model was based on each row within the table containing individual pieces of data. SQL databases based on this design would create joins that would reconnect the entire relation back together, suffering performance limitations.[5]

In the object database design, instead of using multiple tables to store a data object, it is stored in one a single record. This keeps the entire object intact and reducing the need to join the data back together. This process of storing the entire object in one table reduces the total amount to lock, reads and write operations required. It is also this ability to store an object in one record that reduce the amount of file reads and writes, which enables the object design to maintain efficiency with very large and very complex database designs.

Looking at the images to the right, the on above depicts the relational model and has the data spread over two tables, with the parent in amber and the children in blue. In the object model, both the parent and children are stored in the one data record, the information that was previously stored within the related table is now stored within the sub or nested table of Foo.

All objects within the database are referenced by their object identifier which is itself managed via a static hash index. A static hash index is simply an array index where the location containing the address of the object is deduced by taking the ID value, multiplying it by 12 and adding an offset value. This reveals the location of the physical address of the object. This method translating the ID into its physical address enables true order one (O(1)) retrieval of data, regardless of how many objects are stored within the database.

Imposing the static has index on all table schemata allows for real-time compaction of the file, as object locks are on the index and not the object itself. This than allows for even locked objects to be moved within the file by other transactions that require more space or are deleting objects from the file. This ability to move objects within the file at any time also imposes the need to access the via the index,[8] while SQL databases may scan through all records by scanning the file from beginning to the end, the real-time compaction prohibits this style of access.

The B+ tree index is the primary workhorse of all databases and ODBPP is no exception. The majority of searches are carried out via seeking an index position than repetitively call for the next largest value. ODBPP supports a large number of filters on the B+ Tree to make the results more usable. For example, it can be set to convert all lower case characters to upper case, or set for the removal white spaces or non-alphanumerical characters, and also provide a natural sort order where '9' is before '10'.

One of the features of ODBPP over the standard DBMS is that data stored within hierarchical object can also be indexed. This will then create a situation where there are 0…n index values created for any one object.

Spatial indexes are used to allow searching on both two- and three-dimensional coordinates spaces. Temporal indexes are a similar idea along a one dimensional of time.

ODBPP also supports sets of spatial data that represent key points of both two and three dimension objects such as finger print or human faces. These sets are indexed via a Spatial index which allow for group searching. The search itself will create a temporary index that has as many objects that have at least the search pattern or more points within a given error.

ODBPP provides full text indexing via the token list indexes. These indexes are a combination of the B+ Tree and an bucket overflow, where a text string is broken up into its individual tokens and indexed into a B+ Tree and since multiple object will have the same token value, the ID is stored in a bucket overflow (similar to dynamic hashing. With this design, full text searches are done by scanning through all tokens in the B+ Tree leaves and identifying which tokens fit the search criteria and retrieving the matching IDs.

The full text search query also provide set logic functions to reduce the search results to a number that is usable. It allow the user to search of objects that contain token A and not token B for example.

ODBPP has been designed to function in both a procedural style and encapsulated object C++ style. Although the object style still uses the procedural method to interface with the database at the low level, in the example the procedural method is demonstrated.

The equivalent TScript example of reading an object from the database that has the name "FooName" is as follows.

#include "ODBPP.ts"

public main(variable parameters = null : Structure results) {
   ODBPP database;
   ODBPP.Object objectHandle;
   database.OpenDatabase(L"c:\\Path\\To\\Database.odc");
   database.BeginTransaction();
   database.OpenTable(1);
   database.ReadIndex(1,CODBPP.EQUALTO,1,L"FooName": objectHandle);
   database.FragmentObject(1,objectHandle:results);
   System::MessageBox(L"Parent = "+results.ParentID+L", Flags = "+results.Flags);
}

ObjectDatabase++ is also exposed via COM wrapper class 'ODBPPLib.ODBPP'. The equivalent C# example of reading an object from the database that has the name "FooName" is as follows.

private void button1_Click(object sender, EventArgs e) {
    try {
        ODBPPLib.ODBPP odbpp = new ODBPPLib.ODBPP();
        odbpp.OpenDatabase(@"C:\Path\To\Database.odc");
        odbpp.BeginTransaction(odbpp.SHARED, 6000);
        odbpp.OpenTable(1);
        ODBPPLib.DatabaseObject results = odbpp.ReadObject(1, odbpp.EQUALTO, 1, "FooName");
        if (results != null)
            MessageBox.Show("Parent = " + results.readField("ParentID") + ", Flags = " + results.readField("Flags"));
    }
    catch (Exception e1) {
        MessageBox.Show(e1.Message);
    }
}