Re: Dreaming About Redesigning SQL

Wol,

> I think one MAJOR problem is that most (if not all) MV practitioners are
> not formally qualified in computing ...
<snip>
> "Relational" is all about theory and proving things mathematically
> correct. "MV" is all about engineering and getting the result. And if
> that means pinching all the best ideas we can find from relational, then
> we're engineers - of course we'll do it :-)

So what you're saying is that you use MV databases becuase you find them
easier to understand and set up than relational databases. Sure. For that
matter, spreadsheets are easier to understand and set up than relational
databases -- or MV databases, for that matter.

I've no problem with the idea that MV databases are easier for the neophyte to
understand. But you seem to be making this bizarre logical leap that "easier
to understand without training" == "technically superior".

And I noticed that you have completely backed off from your assertion that
there was some kind of MV database theory without ever addressing it.

> As soon as a requirement for a database specifies extraction of the
> maximum power from the box, it OUGHT to rule out all the current
> relational databases. MV flattens it for it for performance. As an MV
> programmer, I *KNOW* that I can find any thing I'm looking for (or find
> out it doesn't exist) with just ONE disk seek. A relational programmer
> has to ask the db "does this exist" and hope the db is optimised to be
> able to return the result quickly.

Well, frankly, no. You're confusing your floundering because you find it
hard to grasp relational database design and/or have a badly designed
database with a performance problem. There are several people in our
community running large genetics databases on PostgreSQL, using good
relational design, and doing well with them.

> To quote the Pick FAQ "SQL optimises
> the easy task of finding stuff in memory. Pick optimises the hard task
> of getting it into memory in the first place".

And hope to the gods that nobody pulls the power cord.

> "Relational" is all about theory and proving things mathematically
> correct. "MV" is all about engineering and getting the result. And if
> that means pinching all the best ideas we can find from relational, then
> we're engineers - of course we'll do it :-)

"Relational" is all about preserving the *long-term* integrity, utility, and
accessability of your data. "MV" is all about getting an expedient result
immediately and to heck with the future.

Read some of E.F. Codd's original papers ... he was not concerned with
expanding some obscure batch of mathematics, he was concerned with the
problems of data that wasn't clean, or wasn't the same when you queried it
twice, or data with rules that changed eraticaly over time, and wasn't
portable at all. These are real, "engineering" problems that needed solving
and relational theory solved it.

> . Unless you can use set theory to predict
> the future, relational has nothing to do with science ...

I wasn't aware that clairvoyance was a tenet of the scientific method.
Science is about reproducing reliable results, which is also what relational
theory is about.

To conclude: Your entire advocacy of Pick can be summed up as "I like Pick
and find it easy to program, therefore it is superior." Well, Wol, that
makes it superior for *you* but not for the rest of us. If you want to use
Pick and not PostgreSQL, go for it; but if you barge in here and try to
convince us that Pick is superior based strictly on your say-so, you've
become one of the crazy preachers on Sproul Plaza.

--
Josh Berkus
Aglio Database Solutions
San Francisco