Re: Unknown SQL

Philip Lijnzaad wrote:
[Views]
> Carl> It seemed that views where evaluated and retrieved completely before
> Carl> constraining them by other parts of the query.
>
> which I still find hard to believe; I would consider a database that
> implements queries on views this way, broken (that is, in the general
 case;
> in certain queries it may of course be decided that this is optimal).

Did we discuss this the last time?
Indeed, we also found this behaviour very strange. Some of the views we used were very complex though. Query optimizers always are bound to have limits to what they "understand".

> I still disagree with this vehemently, at least for Oracle because that's
 the
> only database I have access too. In all cases, views performed as well as
> fully expanded queries on base tables.

I can only talk about my own experiences with Oracle 7 and relatively complex views.

Even with normal queries I remember the Oracle 8 query optimizer to be very grateful for every additional constraint added to the WHERE clause, even if keys would have provided a logical "smallest bucket" evaluation path.

Going from the "have tried" facts to the "have heard" beliefs: I have read quite a few recommendations, that IBMs DB2 query optimizer is comparatively better.

> Carl> Why are you talking about pointers?
> Carl> We use Java.
> Carl> There are no pointers.
>
> Surely you realize that 'references' ('generalized pointers'), not
 'hardware
> memory addresses' was meant here.
 

:-)
Yes.
Sometimes I do get tired of arguments like "You don't know what views are." or "You have neve understood what relational is all about." They tempt me to throw sand into the eyes of the discussion partner.

> Carl> If relational databases will not learn to disassemble objects and to
 put
> Carl> them back together again (= storing references) they will have no
 future.
>
> Mmmm ... given the current situation, that's a fairly extraordinary claim,
> which consequently will require fairly extraordinary proof :-)

The current situation does not back my comment up at all, I agree. I hope to live and work long enough to see a change.

> OO schemas have a habit of being very rigid, i.e.
> not flexible enough to easily adapt to new situations
> and requirements.

True.
Commenting on a possible solution would put me totally on the nerd side of credibility.

> But the essence of large of amounts of data _is_ those values; they are
 just
> a bit more 'raw' than fully composed objects. They have proven to be
 flexible
> and adaptable to unforeseen future needs. E.g., they allow more general
> 'browsing' (such 'mining' is an example of an 'unforeseen way of
 accessing'
> to the data)

I don't disagree at all. Declarative queries for object databases (the original thread) could improve the situation for object databases.

> Carl> Normalization is unnecessary and ugly if you can store objects.
>
> Surely you don't mean to imply that OODBMSs need not be normalized? That
> would be pretty disastrous (think 'update anomalies'). Date or Celko has
> said: normalization is Analysis, not Design, and I think there is truth in
> that.
>
> You may, however, you refer to the need for splicing an object's
 multi-valued
> attributes into a different table in order to comply with 1st normal form.

Yes.
Thanks for putting this right.

> If the argument is that relational databases don't distinguish between the
> storage of entities, weak entities and/or multi-valued attributes: agreed,
> this is not visible in the table structure (but it would be in the
 cascading
> deletes, or, for that matter, an object relational layer).

There are lots and lots of paradigms to learn here. Are they all necessary?

> The big argument
> in favour of it is that this makes the query model uniform, and it makes
> things more easily extendible in case a weak entity or attribute is
 promoted
> to a proper entity. No schema changes! These things are actually a concern
> with large scale data management. E.g., sometimes a one-to-many
 relationship
> is implemented using a link table (ie., as if it were a many-to-many
> relationship), just to anticipate the relationship changing from a
> one-to-many into a many-to-many relationship. I don't see how you could
> achieve this kind of generality and flexibility with OODBMSs.

I do see advantages of a flat query model and flat output to table form for some usecases.

Using in-between-link-objects is also possible with object databases.

Yes, of couse every additional abstraction layer provides a place for a more general (or more flexible) handling. A defined layer also allows to map to objects in many different ways. If this is what you want, you could also realise it by using a layer of more abstract objects in an object database. The final step would be very awkward: You could simulate a relational database.

Cheers, Carl

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