Re: Flamewar object databases vs. relational databases

Todd Gillespie wrote:
> : class Person
> : class Employee extends Person
>
> You have extensive examples for attribute and implementation (is-a)
> inheritance. Could you perhaps cover composition (has-a), and how each
> system would handle it differently?

Lets take Java as the example for composition (has-a) for object databases. Composition is represented by Interfaces. Interfaces do not change the actual stored data, they only change the views other objects get. "Has-A" values are very nicely calculated in real time during the access to a method. If you only access objects through methods, you can beautifully change the implementation on how values are really stored, without any change outside of your changed object,

Relational databases have clear advantages for: - multiple inheritance constructs, since a normalized database design does not care about hierarchies. Join whatever you wish in whatever way you like. Everything is at one level. A relational database does not care if another table is a parent, a child or an umpteenth parent. - shifting inheritances and models among the data. Declarative update queries with similar power are not supported by current object databases. This advantage is easily lost by code adjustments in applications to reflect the changes to the relational model.
- views on data that include instant calculations and grouping. Object database query languages currently do not support these features in the same manner.

Are these short lines O.K. to start a dicussion?

Kind regards,
Carl

---
Carl Rosenberger
db4o - database for objects - http://www.db4o.com