Re: The Practical Benefits of the Relational Model

> Isn't that what the notion
> of using a distinct language for relational operations is about?!

I think you are right, but I think we ended up in that situation by accident, rather than intent.

I would say that SQL became the de facto standard language for data exchange between applications and databases more or less the same way that other de facto standards come into being. It has to do with being in the right place at the right time.

Since relational DBMS systems had functions for supporting relational operations, and programming languages did not, it seemed to make sense to allow the SQL SELECT statement to include reference to all the relational operators that the DBMS supported. In essence, the SELECT allows a view to be specified and requested in one step. I think that made sense at the time.

Given that situation, it was only a matter of time before programmers began to use tables managed by an RDBMS for the sake of being able to join, etc. rather than for the traditional reasons one puts some data in a database. So, you end up with the SQL being an add in to procedural languages, for the sake of relational functionality, and not just an interface, for the sake of data exchange. Your critique of that state of affairs is spot on, IMO.

At this stage, my question is, "what makes sense, going forward?" Should a new language be developed, that takes on a different from SQL's mission, but one that overlaps SQL's mission? It sounds, from the discussion of "D" and its family of languages, as though the answer is "yes", at least for some of the important authors. If a new language is developed, is that going to increase or decrease the total amount of confusion generated by the present plethora of languages? Does anybody care? Received on Wed Sep 18 2002 - 17:28:01 CEST