Re: Cocoa/EOF for non-enterprise apps Re: proof of cocoa superiority?
Re: Cocoa/EOF for non-enterprise apps Re: proof of cocoa superiority?
- Subject: Re: Cocoa/EOF for non-enterprise apps Re: proof of cocoa superiority?
- From: email@hidden
- Date: Wed, 13 Jun 2001 10:19:31 -0700
>
The most complex SQL statement I've ever written was 19 pages long,
>
joining 23 tables with several levels of nested subqueries. It also
>
joined the same table to itself five times to generate a report (one
>
column for each possible field value rather than one column for all
>
field values). I'm frankly amazed the parser didn't harf (Oracle 6 at
>
the time).
We must have different ideas as to what constitutes a "long time" to write
=). The time it takes simply to type 19 pages would fall into a "long
time" in my mind, but I'm the impatient sort. Not that I haven't spent
large amounts of time on many projects, but...
In my experience, however, it's not primarily the length of the SQL that
makes it take a long time to write. I have a chunk of SQL that's about 3
pages long that hits 11 tables, but it has a huge number of nested
subselects, many that are introspective. The biggest problem is that some
of the tables are massively denormalized, which makes the associations
necessary to avoid cartesian return complex and numerous.
>
Let's just say I'd be very surprised if EOF could do it.
EOF? I'm surprised the database optimizer could handle it without giving
you mostly row scans and lazy spools. Oh, wait, if you were on Oracle 6,
you were using the rule-based optimizer so YOU were the optimizer. Yuck.
>
There were big changes from Oracle 6 to 7 and 7 to 8. 7 to 8 was
>
easier to maintain and the interstatement view support (for
>
statements like below) is improved. I'm less familiar with the
>
histories of other large SQL databases as I was exposed to them much
>
later.
Oracle has a particularly volatile history, but other databases have
similar histories. But I still stand by my statement, we are (IMHO) at a
fairly stable point in DB development. I doubt we'll see big changes AWAY
from standards from here on, so I don't think maintaining the adapters
would be that huge of a task.