For better understanding of this document it is necessary to read sections of the documentation language extensions and especially attentively the chapter OO-model. If you won't understand them - further reading has no sense.
CODB consists of the dictionary ( metadata storehouse ) and a number of depositories for data objects.
CODB is not OO storehouse as it is in classical OO-programming (C ++, SmallTalk...). CODB is an object database, i.e. storehouse of objects with some OO elements.
In particular, the "private" properties is not supported - for the simple reason that CODB core must know about all properties of an object. But instead of "private" there is an opportunity to store objects with properties, which aren't described in metadata.
Thus, if the object with extra properties will be stored, using the method method depository:append(obj), all those extra properties will be kept completely, but the type checking, content checking and indexation will not work for them.
While reading such an object all properties will be accessible and the programmer is fully responsible for the content of those extra properties. If he will not describe them in the documentation, they may be considered as "private" :).
Inheritance is supported, but only from one superclass, and the properties and indexes are inherited only.
Polymorphism currently is not supported, because object methods are not kept. Possibly, the following versions of CODB will support object methods keeping and polymorphism. Currently only event handlers ( analogues of triggers in RDBMS ) are available - it is possible to realize polymorphism partially using them, if necessary.
Main concepts:
| Class | the set of substances with identical properties |
| Object | the substance belonging to any class |
| The stored object | object which is kept in storehouse, there is other name for such objects - "permanent" or "constant" |
| The comment: | |
| In some ODB, especially based on C ++, the metadata are not permanent. In such ODB metadata are known only at compile time and are not kept in dictionaries. In CODB both metadata and the stored data are permanent because they are kept in DB and are accessible at run-time | |
| Property | a part of an object, the attribute of an object, it may be of any type |
| Method | a program code which an object may execute |
| Metadata | objects which describes the structure of other objects |
| Dictionary | storehouse of metadata |
| Depository | a place where stored objects are kept ( the structure of these objects is described in the dictionary ) |
| Essence | a string which describes the content of stored object |
| Extent | a part of depository for storage of related objects belonging to different classes. The fragmentation of depositry on extents depends on the essence of the whole data kept, the number of stored objects, their relations etc. It is defined at a design time |
If to consider these concepts from the point of RDBMS:
| CODB | RDBMS |
| Dictionary | a place where descriptions of databases, tables, fields, users, views, triggers and others is stored |
| Metadata | the data used by RDBMS for the internal needs |
| Depository | database |
| Extent | this concept is not present in RDBMS, but it may be a part of database, which keeps some tables. For example, tables which names begins with a letter "A", a letter "B", ..... |
| Class | the table |
| Object | a record of the table |
| Property | a field of a record |
Theoretically CODB may keep the data in any low level storehouse: TXT, SDF, XML, DBF, SQL, others ODB, CORBA... At the present time only a driver for DBF+CDX files is implemented. The driver is written on CLIP, it's sources are about 60k.
Identification of all objects is global, i.e. using the identifier of an object it is possible to determine the dictionary and depository it is related to. The length of the identifier of an object is defined at compile time, the configuration is in codbcfg.ch. In a standard configuration the identifier of any object ( meta or stored ) occupies 12 bytes and consists of:
The identifier of the dictionary - 5 bytes.
The identifier of the depository - 2 bytes.
The identifier of an object in depository - 5 bytes.
Only Latin letters and digits are used in the identifier, so the number of dictionaries is no more than 32^5 = 2^25 = ~32 000 000. At each dictionary there may be 32^2 = ~1000 depositories. The number of extents inside the depository is limited only by the number of files in the directory or number of tables supported by RDBMS. The number of objects in one depository is no more than 32^5 = ~32 000 000.
The speed of objects recording to the database using the DBF driver is about 200 per second ( Celeron 400/128M ), it depends on the size of object slightly. The speed of reading without caching is about 2000 per second. If an application server and objects caching will be used, the speed of reading will increase presumably in 3-4 times.