OODBs?

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 <[hidden email]> wrote:

On Wed, 06 Jun 2007 18:06:15 -0700, Chris Muller <[hidden email]>  
wrote:

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.

On Thu, 07 Jun 2007 17:26:26 -0700, James Foster <[hidden email]>  
wrote:

> On Thursday 07 June 2007 11:35 am, you wrote:
>> That's cool. Are there any Smalltalk reporting tools?
>
> No more (or less) than with any other Smalltalk. Some of our customers  
> are
> using VA Smalltalk and a third-party add-on called "Visibility" (see
> http://www.totallyobjects.com/Viscol.htm).


Interesting. I know there are some banks that use ST  
extensively....perhaps they have internally generated tools?

On Jun 8, 2007, at 9:55 AM, Blake wrote:

No, they generally use O/R mappers into relational databases (I am  
thinking of a specific bank headquartered in my area whose Smalltalk  
employees I know). O/R mappers are not OODB's, they just *emulate*  
OODB's (e.g. Glorp).

--
-Brian
http://briantrice.com

On Fri, 08 Jun 2007 16:17:03 -0700, Brian Rice <[hidden email]> wrote:

Why...why...why....THAT'S CHEATING!!!! ;-)