Re: Decline of Science: Computer Science and Databases

From: Paul Vernon <paul.vernon_at_ukk.ibmm.comm>
Date: Mon, 11 Nov 2002 18:21:27 -0000
Message-ID: <aqosgq$pli$>

"Carl Rosenberger" <> wrote in message news:aqhihs$eum$02$
> Leandro Guimarăes Faria Corsetti Dutra wrote:
> > > Obviously, since you know SQL and S.O.D.A. is new.
> >
> > No. Since SQL is simple, logical and relatively concise. Compare that
> > to your long-winded, complex statements.
> I think you didn't look exactly.
> SQL doesn't support the features I posted.
> (1) How would you query for *all* rows in *all* tables that
> contain the column "name" ?

SchemaSQL is one approach to tackle that kind of 'problem' (I think). Go google.

> (2) SQL doesn't know what interfaces are.
> (3) It is not possible to execute server-side Java code from
> within a query statement on most SQL databases that I know.

Pretty sure DB2 can do that (Java UDFs), but it's not my area.

> (4) How would you query for a regular expression?

Get re's into the SQL standard. It will happen, just don't know when.

> (6) In the UNION example I posted, the WHERE clause is used
> for both "tables". Imagine a more complex query with a dozen
> classes and a dozen constraints. In an SQL UNION statement
> you would need 144 WHERE expressions, S.O.D.A. only needs 12.

If the WHEREs are all the same, do the UNION first, then restrict the result. A good optimiser will push-down the where clause if performance is your thing.

> (7) An SQL system always requires you to "navigate" from parent
> to child by IDs. S.O.D.A. understands class structures and it
> understands Collections, so you only need to use the member
> name.
> I apologize for the examples being too simple to point out the
> benefits. I have been away from end-user-applications for a
> couple of years now and I am pretty bad at writing samples but
> I do remember the principle of the requirements that we had very
> well.
> > This still doesn't explain the huge difference in both size and
> > legibility.
> As soon as examples get a little more complex, S.O.D.A.
> benefits from object-orientation and query set-up code
> will be much more legible than SQL:
> You can build up parts of the query in separate methods
> and you can reuse methods. Objects can be added to the
> query graph one at a time.
> This is not possible with SQL. As soon as things get complicated,
> SQL starts to be a pain. Here is an example from my past:
> (see the end of the posting)
> The statement was generated with a query generator because SQL
> statements of this order of complexity could not be built by hand.

Humm, nice SQL. Obviously the db design was not good, but again I wonder if SchemaSQL would help on that example. (Not that I'm overly sure that SchemaSQL is good idea itself, but it's certainly food for thought for us SQL folks)

Paul Vernon
Business Intelligence, IBM Global Services Received on Mon Nov 11 2002 - 19:21:27 CET

Original text of this message