Re: Dreaming About Redesigning SQL

On Mon, 06 Oct 2003 23:07:33 -0700, Seun Osewa wrote:

> 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?
>
> ** of the ease with which SQL can be used from within all programming
> languages and as an interactive query language?
>
> ** The failure or earlier models and the support of major SQL database
> vendors once it reached critical mass of adoption?
>
> In other words do we have the model, the language, or standardisation to
> blame/praise for the popularity of the relational model?
>
> 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".
>
> ** 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.
>
> 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.
>
> Seun Osewa
>
> Lee Fesperman <firstsql_at_ix.netcom.com> wrote in message
> news:<3F7F8E1A.474_at_ix.netcom.com>...

>> Seun Osewa wrote:
>> > Sometimes I wonder why its so important to model data in the "rela-
>> > tional way", to think of data in form of sets of tuples rather than
>> > tables or lists or whatever.  I mean, though its elegant and based on
>> > mathematical principles I would like to know why its the _right_
>> > model to follow in designing a DBMS (or database).  The way my mind
>> > sees it, should we not rather be interested in what works?
>> 
>> Relational is the _right_ model because 'it works'. It's the only truly
>> comprehensive data model and subject of decades of research. All other
>> data models have been found to be flawed and (nearly) discarded.

The RDBMS wound up as the most popular approach to DBMS for practical business reasons. The premier DBMS at the time of the introduction of Oracle (the first RDBMS to hit the market) was IBM's IMS. IMS was much faster than Oracle and, given the concern about system performance in an era where supercomputers didn't have the performance of a Pentium, the fact that Oracle and subsequent RDBMS became more popular was due to the one factor which concerned businesses even more than bang for the buck.

This was the cost of maintaining a working system. The primary advantage of the RDBMS over its predecessors in the 1970's was that the RDBMS was dynamic, while most of its predecessors were static. By that I mean that if the world changed it was easy to change the RDBMS model and code to meet the changing conditions. This was not the case with the alternatives.

IMS was designed to optimize performance and, from what I recall, was very difficult to change. Even trivial changes in the real world could result in massive reprogramming efforts. Things were so bad that in some cases once the world started to change the programmers could barely keep pace and the use of a database became a liability rather than an asset. Received on Wed Oct 08 2003 - 02:29:57 CEST