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

Philip Lijnzaad wrote:
> Carl> This is where I see one of the largest advantages of relational
 databases:
> Carl> You can always set up a two-dimensional table of your result, which
 is
> Carl> instantaniously readable by a human.
>
> yes, but it also comes in very handy if you want to find/update/delete a
 set
> of objects based on some complicated predicate. I.e., I think it's fine if
> the OR contains complex hand-crafted queries, e.g. for report generation.

No doubt.
Report generation is one of the great advantages.

Earlier in this thread someone has been talking about the need for an ad hoc and complete string query language for:
- testing purposes
- experimenting with new views on the data

This is where SQL is very good.

[using a vertical database design with one table per class]
> Carl> Now would you be so kind to write a query that completely puts all
> Carl> person objects back together again, with the following addition to
 the
> Carl> datamodel: - customer extends person - sponsor extends person - VC
> Carl> extends sponsor - self_employed extends employee
>
> Carl> I bet, I will be faster:
> Carl> database.get(person)
>
> No, exactly these kinds of queries is trivial; it's still
>
> select * from person;

No, sorry,
putting objects back together *completely* will not be solved by the above. You also need the data specific to the respective classes, stored in the tables emloyee, manager, customer, sponsor, and VC.

> yes, that is true and important, but that's not what I mean. If you have
 to
> add a customer_contact table because you now want to allow more than one
> contact per customer, you can just add the table, and create the views
 that
> make the thing behave as if the old 'one contact per customer' situation
 was
> still the case. The old application continues to keep working, and you can
> start adjusting the object layer and the applications.

A good example!

Ideally an OO implementation also capsules all access to class members in methods. You would only need to
- change the implementation behind accessor functions. - run a declarative UPDATE query to reorganize objects.

> Carl> Sorry for my bad wording. The negative performance hit occurs when
> Carl> queries join views with other views or tables. Most (all ?) current
> Carl> query optimizers build all views first (run all underlying queries),
> Carl> before evaluating them against eachother.
>
> This would be a very stupid way to implement queries involving views.

Maybe I am not up-to-date with the latest technology here. The research we did two years ago (on ORACLE databases among others) seemed to prove by the timed responses that exactly the above was happening.

Cheers,
Carl Received on Mon May 14 2001 - 12:42:33 CDT