Home Forums SQLServerCentral.com Editorials Why Object Databases will always be Tomorrow's Technology RE: Why Object Databases will always be Tomorrow's Technology

  • It's always seemed to me that an OODBMS and an RDBMS would be two very different beasts, but both would be useful for different things.  There's no reason why ACID properties can't be implemented in an OODBMS, and no reason why backup and restore can't be implemented either.   Problems probably would arise if the an OODBMS used a thoroughly broken language like C++ or a hopeless mess like Java as its model for object orientation, but there are some decent OO Languages out there that wouldn't create problems.   Big problems would arise if one were to use an OODBMS for something for which it was not suitable, just as they do when an RDBMS is used for something that isn't suitable. 

    One problem some time ago ago was that a lot of people were designing OO databases without an OODBMS, while another lot were designing OODBMSs that omitted at least one of ACID, Backup/Recovery, and Object Orientation, but there was similar silliness on the relational side. I remember people who wanted to use an OO DBMS but were horrified by the idea that calling a method of an object in the database might lead to it sending messages to other objects which in turn might send messages of their own: they didn't want objects in the database to behave as objects;  and also relational database fans who were horrified by triggers, regarded cascading deletes/updates as a terrible sin, and refused to enable their foreign key constraints because they believed it would destroy performance.   I stringly suspect that we still have those problems today.

    Anyway, my feeling is that eventually everyone will recognise that it's case of horses for courses and both OO and R have their place.  There's no possibility that Relational databases will cease to be used because they are supeceded by OO Database technology, nor any possibility that OO databases will cease to be used because evryone used Relational instead.   However, it's quite possible that a better query language than SQL will arise on the Relational side, and that a decent mostly declarative query language will arise on the OO side.

    Tom