phdru.name / Software / OODB
An OODB stores objects; actually serialized images of objects, and serializes and deserializes objects at needs. An OODB assigns every object an OID (object ID) and stores a global mapping from OIDs to objects.
A user can and should create "indices" - mappings from keys to objects (or OIDs). These indices help to fetch objects; they also are there to be iterated over, so the user does not need to fetch and test an every object in the loop (which can be quite memory- and time-consuming) - it is enough to iterate over an index and fetch only those objects that the user really needs; the index iteration is usually optimized time- and memory-wise.
Serialized objects are the only "things" in a database. Indices are also such objects.
Storing and fetching objects are the only operations (beside administration tasks, like packing) of an OODB. Removing objects is (sometimes? usually? always?) implemented as a modification of the parent object - the OODB breaks the link between the parent and the child, and stores the modified parent object. Index iteration is not a task of the OODB - indices are just special iterable objects (sequences or enumerators), usually implemented as trees for efficiency.
Creating and deleting objects (including indices), and iterating over indices are main (if not the only) tasks related to OODBs that a user performs. All other manipulations with objects are outside the scope of OODBs, though OODBs that support transparent persistence take notes when objects are modified and store (serialize) new and modified objects at the end of a transaction.
When developing programs a user is mainly confronted with the following 4 problems related to OODBs:
This is the page https://phdru.name/Software/OODB/OODB.html. It was generated on Sun, 16 Jun 2024 10:04:49 GMT from CheetahTemplate OODB.tmpl. Some rights are reserved. Read more about technical aspects of the site.