I've never actually worked with an object orientated database but from my understanding they are much more flexible then relational database, unfortunately this in turn means that they are more difficult to manage.
Of course, this is just what I have heard and I could quite happily be proven wrong.
User-Defined datatypes & Objects
Fully compatible with relational Database
Support for Multimedia and Large objects
High-Quality database server features
Improved performance & Functionality of OnLine Transaction Processing (OLTP) applications.
Better sharing os Run-time data structures
Operaqting within the Network Computing Architecture (NCA) Framewotk
Can scale tens of thousands of concurrent Users
RDBMS Features :
Its based on the Relational model proposed by Dr.E.F.Codd
Its a collection of objects & relations.
It contains set of operators to act on the relations
It provides Data Integrity for accuracy & Consistency
can be accessed & Modified by executing structured query language(SQL) statements
As the name implies , Object Oriented Dbs are implementing Object Oriented Concepts in Relational Dbs. OO Dbs are fully compatible with relational Database. So there's no issue of Relational Db over Performing OO Dbs.
Also, am I right in saying that when mapping oo to relational db's they dont map well. - I take it that the OO classes are designed using the application (which is of oo nature) then stored on a relational database, this is when the mapping problem occurs.
But why store on relational db, and not oo db? this would cure the mapping probleM right? im confused.
why is there a reuqirement to store objects and map them to a relational database? can anyone explain?
It is about ways we organise knowledge in our brain. From my angle, it appears RDBMS is for older people, while OO is for younger ones. Sadly, I grew to belong to the first category, but I used to think OO a few decades ago.
As a young person, I was gathering knowledge, as if pealing an onion. There was always something new to discover, when going down from layer to layer. A human individual, or a financial transaction, or a transistor would provide ever more complex characteristics, so it was quite convenient to encapsulate such a things as "objects".
After a while though, it turned out that real complexity lies outside the objects, in the relations which bind them together. By now, I'm less interested in the full complexity of a human being, as long as he or she behaves like a customer.
I'm not saying OO-modeling is unnecessary. Quite the opposite. What I am saying is that we already operate with well-established "objects". The concepts or Money, Account, Transaction, Customer, Legal Entity are abstractions, which reduce complex reality to a few essential attributes. These entities are understood by everyone, and they can easily be modeled with a couple of columns in a relational table. On the other hand, things like a GUI Api are (were) subject to change and internal evolution, just like the proverbial radar station of Grady Booch. When the reality is less understood, then OO comes out better.
The relational space may be populated by bland, simple entities, but it is far from boring. A bank account is a simple model: you can only post an amount, or look at the balance. But managing the totality of accounts in a bank is quite complex. That sort of complexity appears outside the individual account. Therefore, an account record in a relational table is just as good for this purpose as an account object. It is also simpler and faster. That's why I'm reading dbForums.