Invisible wrote:
> Yeah, well, I have little concept of what other kinds of databases have 
> existed other than relational ones.

Relational pretty much replaced *everything*, and then along came OODBs and 
along came distributed databases.

> (We did hear some talk at uni about people working on object databases, 
> but nobody could really figure out precisely what such a term means...)

It means it doesn't follow the relational model, but instead the OO model. 
For example, say you're using an OO language. (I'll assume you know how OO 
languages work.) At some point, you say "stick this object in the database." 
It says "OK." Then you can exit. When you start up again, that object is 
still around, as well as anything it had pointers to in member variables.

It's nice because you can stick big blobs of data in and efficiently fetch 
and store it all at once. So something like "my facebook account" would be 
one record, or "this wiki page with all the history, embedded images, etc", 
or Amazon with "this product, all its pictures, descriptions, reviews, 
keywords, tags, etc". When much of your work is with one large record, you 
can fetch it, use it, and put it back with relatively little overhead 
compared to the RDBM.

The hard part is when you want to do something like (say) add up the amount 
of money in all outstanding shopping carts, and you have to figure out how 
to iterate over the objects without sucking the entire user's account into 
memory for each one. If you can fit one entire table into memory, this is 
less of a problem, but obviously still not trivial.

The advantage of an OODB is that you don't have to write a lot of code to 
deal with format changes between what you store on disk and what you store 
in memory. The disadvantage is that the only easy way to get to it is 
usually the way it's stored in memory.

-- 
   Darren New, San Diego CA, USA (PST)
   "Ouch ouch ouch!"
   "What's wrong? Noodles too hot?"
   "No, I have Chopstick Tunnel Syndrome."

Post a reply to this message