I have a question for anyone who has worked on the internals of a OODB. To wit:
Is the underlying data in an OODB typically stored in relational tables?
If, for example, you had a "person" object, and then subclasses of "employee" and "customer", would there be three tables with the common info in "person" joined to "employee" and "customer" respectively?
Yes, but not relational tables in the sense of a relational database. OBDMS's still have to capture the shape of the object graph, and for that "one big table" is typically used.
For example, one approach might try to keep the edges with one big two-"column" table:
oid | referencedOid
which would have to "join" to itself to render the graph (but might not perform very well).
Magma uses variably-sized "records" that embody the nodes. Every object is represented by a first-class "MaObjectBuffer" with the following fields:
oid | class | referencedOid(1)..referencedOid(n)
You might be interested in the detailed documentation of Magma's file format Brents team put together:
http://wiki.squeak.org/squeak/uploads/2665/magma_file_format.pdf
On 6/6/07, Blake blake@kingdomrpg.com wrote:
I have a question for anyone who has worked on the internals of a OODB. To wit:
Is the underlying data in an OODB typically stored in relational tables?
If, for example, you had a "person" object, and then subclasses of "employee" and "customer", would there be three tables with the common info in "person" joined to "employee" and "customer" respectively?
On Wed, 06 Jun 2007 18:06:15 -0700, Chris Muller asqueaker@gmail.com wrote:
Yes, but not relational tables in the sense of a relational database. OBDMS's still have to capture the shape of the object graph, and for that "one big table" is typically used.
For example, one approach might try to keep the edges with one big two-"column" table:
oid | referencedOid
which would have to "join" to itself to render the graph (but might not perform very well).
Magma uses variably-sized "records" that embody the nodes. Every object is represented by a first-class "MaObjectBuffer" with the following fields:
oid | class | referencedOid(1)..referencedOid(n)
You might be interested in the detailed documentation of Magma's file format Brents team put together:
http://wiki.squeak.org/squeak/uploads/2665/magma_file_format.pdf
Cool, Chris. Thanks!
===Blake===
On Wednesday 06 June 2007 2:31 pm, Blake wrote:
I have a question for anyone who has worked on the internals of a OODB. To wit:
Is the underlying data in an OODB typically stored in relational tables?
If, for example, you had a "person" object, and then subclasses of "employee" and "customer", would there be three tables with the common info in "person" joined to "employee" and "customer" respectively?
In GemStone/S, the objects are stored as objects in the image. The image can be terabytes in size, mind you, but they are just objects in the image. The internal representation is somewhat like in a client Smalltalk, there is a chunk of memory with an object header that includes information like the class. The garbage collector is responsible for moving things around to compact space when an object is no longer referenced.
squeak-dev@lists.squeakfoundation.org