Re: The Practical Benefits of the Relational Model

From: David Cressey <david_at_dcressey.com>
Date: Tue, 17 Sep 2002 15:05:09 GMT
Message-ID: <FwHh9.83$0I3.5085_at_petpeeve.ziplink.net>


>
> Only having to learn one language. No 'impedance mismatch'. Only having to
> define all your UDT, operators, functions once. Not having to manually
> keep the code written in the 'programming language' inline with the
> 'interface language' when the schema changes. Having relational
> capabilities in the 'programming language' - e.g. relational operations on
> local variables. Need I go on?
>

Yes, please do go on, if the remaining values are useful to present. I was asking the question for real, and not rhetorically. I realize in retrospect that it could be read as rhetorical, but that was not my intent.

Your initial list is a good one, and in part, I share your perceptions of the value of having a programming language that can also serve as an interface language (or, if you prefer, having an interface language that can also serve as a programming language).

I'd like to suggest Oracle's PL/SQL as one possible way to look at this question. I don't mean to suggest that PL/SQL is the "right answer" to the problem at hand. All I'm suggesting is that it is a useful one to look at in order to clarify the issues.

As far as your list goes, I'm going to play devil's advocate in what follows. I apologize in advance to anyone who thinks I shouldn't do that.

On the search for a single language. This has been the holy grail of computing since the 1940s. We are further away than we ever were. The reason we can't see it is the same reason that was given for the failure to find the holy grail: we are impure.
Burdening the interface language with becoming the universal programming language will simply weigh the language down to the point where it fails in its initial mission.

On "impedance mismatch". No argument there. At least, I can't think of one.

On not having to manually prevent source code skew when the schema changes. This is not a language issue. The good news is that physical database changes that do not represent logical schema changes can be "encapsulated in side the database", meaning made transparent to the rest of the community. Schema changes that reflect a changed view of the logical data requirements are going to propagate into the application source, regardless of whether the application is coded in one language or more than one language. Source code management and configuration management are issues regardless of whether there is one source language or there are many.

Having relational capabilities in the programming language. No argument there. It would be great to be able to do select, project, join, etc. in the programming language. But aside from defining "relations" as objects upon which relational operators can operate, aren't we talking about a relatively trivial extension of existing languages? Received on Tue Sep 17 2002 - 17:05:09 CEST

Original text of this message