Re: The Practical Benefits of the Relational Model

"David Cressey" <david_at_dcressey.com> wrote in message news:<Lvmh9.79$0I3.4697_at_petpeeve.ziplink.net>...
> Why do people want the interface language to be a complete programming
> language? What does that buy you?

From the DBMS perspective, it makes sense to provide a facility for the definition of "custom" relational operators. So if one subscribes to the concept of a DBMS only supporting an "interface language", then where are such operators defined?

A relational database system with no imperative aspect would be completely functional, and therefore completely static. A read-only database doesn't do us much good. It follows that we must treat the functional aspects of the database as a subsystem within an imperative one. As is the case for many DBMSs, the imperative portion of the overall system may be external to the expression engine (with three basic update operations thrown in). In this design, data types of the database system are matched to those in the procedural language. Chances are, the procedural language will not have direct support for the DBMS' types, especially relation types. The result is that the external language must interface again with the DBMS to perform operations against these data types. This "impedance mismatch" increases complexity while reducing performance and optimizability. The impedance mismatch problem also leads to duplicated logic and degrades implementation independence.

We have hopefully established that imperative operations are a necessary component of a DBMS, and it is rational to view the functional aspects as a facility within the procedural realm. It then follows that we can (and should) provide both within a single language. This consolidates type definition, ensures consistent operations, increases optimization potential, maximizes code reuse, and simplifies the application logic.

From another posting:
> 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.

Why? Not only would I argue that it does not "burden" the "interface language" (functional or expressive subsystem), but I would assert that it helps to generalize and improve it. My argument is perhaps backed by the fact that expressions are an essential part of an imperative language.

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

If by "objects" you mean "types", then yes. It isn't rocket science, but considering nobody currently does it (my organization excepted of course ;-), you would think it were!

As mentioned, the essence of the discussion focuses on the support for relational data types. One way to look at this whole "impedance mismatch" issues is from a perspective of types. It would seem ludicrous to build one language to deal with integers, another to deal with floats, yet another for arrays, etc. Isn't that what the notion of using a distinct language for relational operations is about?!

--
Nathan Allan