Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Conceptual, Logical, and Physical views of data

Re: Conceptual, Logical, and Physical views of data

From: Christopher Browne <cbbrowne_at_acm.org>
Date: Sun, 11 Sep 2005 18:19:26 GMT
Message-ID: <Oy_Ue.472$1G4.47852@news20.bellglobal.com>


> David Cressey wrote:
>>
>> I agree that Marshall is doing fine.
>
> <blush> Thanks guys!
>
>> First, I don't scorn SQL the way true relational bigots do.
>
> I feel similarly. I really like SQL; the ability to joins, for
> example, is an awesome power. I kind of feel about SQL the way I
> feel about Java: sure it could be better, but there are a lot of
> *worse* things out there, so I'm glad of what I've got.

The fact that there's no "better choice" generally available means that even though SQL is quite a pig, it's pretty much necessary to settle for a date with "the pig."

>> Second, I don't think that all programming should be done in a
>> database language like SQL, or that all programs should be under
>> the aegis of a DBMS, like stored procedures in an Oracle database.
>> [...] SQL is simply not general enough to replace all general
>> purpose programming languages. And attempts to make it that
>> general simply interfere with its primary mission, which is to
>> serve as an interface language for data exchange.
>
> While I agree that that's the right choice in today's environments,
> I firmly believe that it is *possible* to design a language for
> which that would not be true.
>
> Today, one has many useful abilities one can do with SQL: joins,
> content-based addressing, declarative integrity constraints. In Java
> (for example) one has a completely different bag of tricks:
> polymorphism, inheritance, modularity, etc. Why must the two sets of
> techniques be completely distinct? Why can't I have a language that
> is simple yet powerful, and gives me the union of these
> capabilities?

The fairly extreme paucity of theoretical justification for the OO stuff suggests otherwise to me.

Try to find a strong theoretical treatise on the basis of object orientedness... I only know of ONE book that seriously attempts any sort of "grand unified theory of OO."

*Reality* is that OO isn't of theoretical interest; it's a number of programming techniques *not* grounded in any conclusive theory.

If OO *were* grounded in "conclusive theory," we wouldn't see every OO language being so distinctly different in its handling of the elements of the "OO bag of tricks." C++ programmers seem to understand objects very differently from the way Java programmers understand them, and you get similarly Huge Differences for each Highly Distinct language with its own particular "take" on OO (e.g. - Smalltalk, CLOS, Self, and so forth).

>> Third, I don't elevate the logical model to the level of idolatry
>> that some relational bigots do.
>
> LOL
>
>> Fourth, I don't believe that relational database theory is the end
>> point of all history, as far as advancements in the fundamental
>> state of the art.
>
> To me, set theory is the "beginning point" of all (math/CS)
> history. Relational theory builds from that. Mikito recently
> commented about just how undeveloped relational algebra is; I
> agree. I think one thing that's going to happen is that it will get
> more developed.

I can't entirely agree, pointedly because of the "OO experience."

The intense "idolatry" for OO despite the paucity of theoretical underpinnings suggests to me that people have been distracted away from having any kind of desire for theoretical underpinnings.

Based on the OO experience, people clearly don't *care* if things can be developed from 'first principles.'

And the similar paucity of interest in following relational theory fits quite nicely.

People would rather have pretty bindings to their OO mapping than have a consistent relational query language. They'd rather have another "Prevaylor" or "Hibernate" library on top of whatever fragmentary SQL support some half-baked database system provides than hear about how "Tutorial D" is a "better SQL."

The prevailing currents simply do not point to there being a general interest in a better-developed relational theory.

>> In particular, I expect "computer database theory" to eventually
>> come up with something that relegates the relational model to
>> history.
>
> Given how foundational set theory is, I'm not sure I agree. I am
> sceptical that we'll ever stop using, say, boolean algebra.
> Likewise I expect that the programming languages of the future will
> have something like join in them.

I'm with you, there.

For there to be something to relegate the RM to history requires one of two things:

  1. That people choose to not care about there being *ANY* model.
     This is actually a pretty tenable position; when so many SQL
     database vendors don't include the word "relational" in their
     marketing collaterial (or don't include it prominently), it
     becomes evident that "relationalness" doesn't matter all that
     much.

 2.  There has to be some new model whose theory subsumes that of the
     RM.

     Newtonian physics was subsumed by Einsteinian "relative physics"
     because the latter could express everything in the former PLUS
     MORE.

     I haven't seen terribly much emerging that would represent a
     "beyond relational" theory.  The Darwen and Date "Third
     Manifesto" isn't that; it's a call to draw back towards
     "relational orthodoxy."

When we see things described as "postrelational," it's not normally something subsuming the older theory; it's rather more like the notion of "postChristian," where the notion isn't of an "enhanced" faith, but rather of casting the faith off out of disinterest. Which fits with 1, not with 2...

-- 
(reverse (concatenate 'string "moc.liamg" "@" "enworbbc"))
http://cbbrowne.com/info/rdbms.html
If we were meant to fly, we wouldn't keep losing our luggage.
Received on Sun Sep 11 2005 - 13:19:26 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US