Re: Dreaming About Redesigning SQL

In article <ba87a3cf.0310062207.1d09cff6_at_posting.google.com>, Seun Osewa <seunosewa_at_inaira.com> writes
>One question that I think must be looked into is this: If SQL
>databases are successful today, is it because:
>** of the relational _model_ they are based on?

This model, because it's mathematically provable, gives Computer Scientists the warm fuzzies ...
>
>** of the ease with which SQL can be used from within all programming
>languages and as an interactive query language?

This is an effect, not a cause. SQL is a naff query language - it's a mathematical notation (which is why computer scientists like it) but an absolute bummer for normal people.
>
>** The failure or earlier models and the support of major SQL database
>vendors once it reached critical mass of adoption?

Well, with IBM behind it, it wasn't hard to reach critical mass ...

Like most things, once the ball starts rolling, it's hard to stop. The fact that it may (or may not) be crap tends to be irrelevant :-)
>
>In other words do we have the model, the language, or standardisation
>to blame/praise for the popularity of the relational model?

I think we have what is called the "network effect" - in other words, it's popular because it's popular. I know that's a circular argument, but in the real world that sort of argument works.
>
>I would also like to know the classical arguments against the network
>model or other "pointer based" models. The only things I know are
>that:

The relational advocates believe that because their model is "mathematical" it must be better than anything else. And all too often they convince themselves that theirs is the only model based on maths - when in fact most of the others are too ...
>
>** using pointers to positions in memory or disk can be messy when
>data has to be moved around. But then is seems there are several
>simple ways to solve this, e.g. what I can only call "logical
>pointers".
>
>** The difficulty of performing adhoc queries. but I want to think
>that if there is a procedural (query?) language many of the advanced
>features of SQL e.g. group by and sorting of the data can be done with
>user-generated procedural code. Then I observe that most databases in
>the world today are being accessed by asp, php or perl web scripts and
>only recieve adhoc queries during the development stage. These
>queries are written by developers who are skilled enough in procedural
>programming not to have problems if they needed such code to access
>the data.

Jan thinks the DBA should determine how the database should be optimised. As a Pickie, I'm used to believing that a DBA shouldn't be necessary. Pick *doesn't* *have* a query optimiser - because it doesn't *need* one. (It's hard to optimise something that's 97% efficient before optimisation.)

Let's design a Pick database. Let's normalise it. And store it in the Pick data structure. I can declare one "table" per entity (with no attribute or relationship tables - I don't need them). Each Pick FILE is equivalent to a relational entity-view.

So, given that I know the primary key of the entity I want to access, it takes me just ONE disk seek to retrieve EVERYTHING about that entity. Its attributes. Its relationships. THE LOT. Now do you see why I say a query optimiser is a waste of time?
>
>Other than that, what's wrong with the network (or similar) models? I
>have not found a good link to such a discussion though I hear it
>repeated that there are certain classical arguments against them.
>
There's nothing wrong with other models. The thing about relational is that it is designed to make "ad hoc" "easy". No one query is harder or easier than any other. The problem is that by reducing all queries to the same difficulty, the "easy" queries are made far harder than they need to be.

Things like hierarchical databases make easy queries easy. The snag is they leave hard queries hard.

But let me leave you with this - why are DB2, MS SQL-server, Oracle all adding multi-dimensional features to their relational databases? I'll tell you. It's because they work - and Pick has had exactly that from the day it was designed nearly 40 years ago. And the typical company that runs Pick as its database spends roughly half (as a percentage of turnover) what a relational-based company spends on its database.

Cheers,
Wol

-- 
Anthony W. Youngman <pixie_at_thewolery.demon.co.uk>
'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the 
thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The man 
lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998
Visit the MaVerick web-site - <http://www.maverick-dbms.org> Open Source Pick