Re: S.O.D.A. database Query API - call for comments

Lee Fesperman wrote:
> There is no 'main' table in a relational query. The result set of a query
 has multiple
> 'viewports'.

Yes, I find this a great disadvantage, as I have stated two times in this thread already. There is no possibility to retrieve a hierarchy of objects. You either need multiple query statements or your result tables get ridiculously large.

By the way:
Only the lack of a 'main' table makes outer joins necessary, to be able to specify where clauses for branches that can be null.

> Yes, I know programmers want to use databases without knowing the basics.
 However, I
> think that is a bad thing.

Your insulting tone shows the lack of other arguments. I do have 5 years of very intense experiences with SQL databases.

> What a 'car' is means different things to different users of the database.
 There are
> multiple 'views' of data in a RDBMS. OO tends to lock into a single view,
 because
> objects that support multiple views of their data are very complex and
 hard to use. By
> predefining all possible links, OO sacrifices power in a shared,
 multi-application
> environment.

I don't understand your argument.
Are we talking about the usage of object-oriented languages?

As soon as there are inheritance hierarchies, I typically find the usage of SQL databases very complex. What is your preferred strategy? - one large table for all classes
- multiple joined tables, one for every class

Using an object database you simply store the object, with no further worries.

Regarding querying the database for unexpected joins: We will try to modify our S.O.D.A. approach to allow to constrain the number of wheels of the car with the number of seats. This should allow for quite a few of those unexpected joins. Thanks for this first hint, what we can improve.

> In relational, there is only one mechanism for linking entities -- by
 using common
> values in table columns. Even you agreed this is a powerful technique.
> In a OO, the
> linking technique can be different in each object. You must learn what
 mechanism is used
> for each object in order to navigate them. This is complexity.

This is wrong.
To reconstruct objects from relational tables you need two unnecessary keys. The reconstructed objects will look the same and navigate the same with both approaches, OO and relational.

In a good object database you do not even have to worry how the objects get put together. The database handles this for you.

- No work for the programmer.
- No sources of error.
- Higher performance.

This is simplicity.

> I was aware from the first where you were coming from, so my
> comments were not always directed to you alone.

I know where I come from but I don't know what you mean here.

> I can't count the number of such solutions to 'improve' database
> that I've seen over the years.

Innovation needs many tries.
Do you imply that SQL is and will be the standard forever?

> They all want to resurrect discarded database techniques
> from the past.

I replied to a similar statement already. Ericsson uses a hierarchical database for mass insert performance and they have achieved excellent benchmark results. I can only repeat my challenge here, that I have just posted to comp.databases. Why don't you benchmark db4o against firstsql?

> Here's another one: http://www.geocities.com/tablizer/sqlcrit.htm ...

I will have a look.
Thanks for supplying further arguments.

Kind regards,
Carl

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