Re: Object-oriented Databases

Hi Benjamin (et al.),

On 27/07/2005, at 10:37 AM, Benjamin J Doherty wrote:

> You overlook (or take for granted) the most significant advantage  
> of the relational database:  integrity and storage efficiency.  The  
> process of normalization in relational theory ensures a level of  
> integrity that to my knowledge cannot be assumed through any OO  
> design practice.  (Of course, I'm assuming that normalization is de  
> rigeur for those of us who work with relational data.)  Don't  
> forget that any DBMS is primarily used for data accuracy, because  
> if the data isn't accurate, why bother storing it in a structured way?

Yes, good points.  It's important, I guess, to distinguish between  
object orientation - modelling with objects - and object-oriented  
database management systems.  The latter would surely be focussed on  
integrity and storage efficiency.

>> Most business applications currently suit RDBMSs, or even better  
>> an Object-Relational Mapping to a RDBMS.  However, I think there  
>> are applications that are more suited to OODBMSs and developers  
>> that use an OODBMS will obtain a competitive advantage from using  
>> them.
>>
>> When I hear Object-Relational Modelling vendors suggesting we keep  
>> our inheritance hierarchy shallow, don't use too many  
>> relationships, keep the model simple, its a warning sign (to me at  
>> least) that perhaps the technology (RDBMS) is not the best  
>> solution going forward.
>>
>
> I've been curious to experiment with the inheritance functionality  
> of Postgresql, because I can see it making vertical inheritance  
> less taxing on the database.  If the CLIENT table extends the  
> PERSON table, the Client object can employ horizontal mapping in  
> EOF to the related Person object, which uses fewer queries, but  
> PGSQL transparently handles the vertical mapping for the  
> application. You have the size and integrity advantages of vertical  
> mapping while only paying for horizontal mapping.

Sounds interesting.  Of course, with an OODBMS these issues don't  
arise (at least for the developers - that's the software developers  
not the OODBMS developers themselves).

> I'm still not entirely clear on the distinction between a OODBMS  
> and a directory.  Inheritance and capacity for a vast object graph  
> are features to both.

By directory, I assume you mean something like "LDAP"?  My (limited)  
understanding of these is that they are a special case - light weight  
(as the name suggests) and tuned for read-mostly.

I think they are quite different than OODBMSs in general.

> Maybe I'm being unimaginative, but I don't see the place of  
> polymorphism in a database outside of SQL functions and procedures.

Of course, it depends what one means by polymorphism.  I think it is  
evident (as you suggest) in querying.  When you query an OODBMS for  
BankAccounts you may also get SavingsAccounts or ChequeAccounts back  
etc.

Not strictly polymorphism (dynamic binding).  However, once these  
objects come back to the application environment they can be treated  
polymorphically (e.g. a deposit in all could work differently).

Cheers,
Ashley.


--
Ashley Aitken
Perth, Western Australia
mrhatken at mac dot com
Skype Name: MrHatken (GMT + 8 Hours!)