Re: Dreaming About Redesigning SQL

seunosewa_at_inaira.com (Seun Osewa) wrote in message news:<ba87a3cf.0310062207.1d09cff6_at_posting.google.com>...
> 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 is the main reason.

>
> ** of the ease with which SQL can be used from within all programming
> languages and as an interactive query language?

I think this "dual mode" concept was proposed by Codd, so in a sense it is part of the "Relational Model"

>
> ** The failure or earlier models and the support of major SQL database
> vendors once it reached critical mass of adoption?

IMS (a hierarchical DBMS) and IDMS (a network, or CODASYL DBMS) were VERY successful in the 70's and 80's. SQL databases had an uphill battle.

>
> In other words do we have the model, the language, or standardisation
> to blame/praise for the popularity of the relational model?

I think the model is the biggest issue. Standardisation has also helped. Many say that QUEL was better than SQL, so maybe we could say "inspite of SQL"

>
> 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:
>
> ** 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".

Well, that's what the relational model does: it uses "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.

If you take a standard SQL-query with sorting and grouping and some joins and compare it with hand written "navigational" code you will notice that what can be expressed in SQL in 5-10 lines of code will require several pages of hand written code for equivalent result. It is also very helpfull to pretest your SQL using a query editor, and when you are convinced of the correctness of your SQL query you just drop it in the program.

The third issue is that the SQL query can be optimised to a much higher degree than procedural code. Say you add a new index. The DBMS will/can immediately start using it without any user intervention (if it decides to). In the procedural alternative you would have to recode your query. The optimiser can also take into account the cardinality of tables (=number of rows) so that it will produce a different plan for a small database and a big database. An optimiser can even be sensitive to input from users at run time, say you have

         select name, salary
            from nurses
            where sex = ?

If the parameter given at run time is 'M' then it could be advantageous to use an index, but not if parameter is 'F'. This decision could be made by the optimiser "on the fly". I hope you get the picture...

>
> 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.

In 1974 there was the BIG DEBATE where Codd defended the RM against network guys. I wonder if there is a transcript available?

I think one of Codds arguments was that the number of manipulative operators needed in the RM (i.e. insert, update, delete) was much lower than in CODASYL (connect, disconnect, etc etc...)

regards,
Lauri Pietarinen Received on Wed Oct 08 2003 - 00:44:03 CEST