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