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: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

From: Marshall <marshall.spight_at_gmail.com>
Date: 2 Jun 2006 10:17:59 -0700
Message-ID: <1149268679.459972.158970@u72g2000cwu.googlegroups.com>


Sasa wrote:
> Marshall wrote:
> > Robert Martin wrote:
> >>On 2006-05-31 11:50:20 -0500, "topmind" <topmind_at_technologist.com> said:
> >>
> >>>I don't see how the issue of proprietary SQL is any different than a
> >>>proprietary app language.
> >>
> >>It's not. I want the application to be isolated from the DB; and I
> >>want the DB isolated from the application. I wan't the application
> >>programmers to be able to change from Oracle to MySQL to Flat files. I
> >>want the DB to have the freedom to support Java, C#, C++ or Python.
> >>
> >>Note the symmetry.
> >
> > I note a tremendous *lack* of symmetry!
> >
> > Java, C#, C++, and Python are comparably expressive, and at
> > comparable levels of abstraction. (I can hear the screams of
> > the language advocates already.) Sure, Python has list
> > comprehensions and C++ has a turing-complete generic type
> > system, but they're all fundamentally imperative and procedural.
> >
> > On the other side, you put together Oracle and flat files!
> > Oracle has natural join; flat files have what exactly? seek()?!
> >
> >
> > Marshall
> >
>
> What if you extend the list of clients with good old .BAT files?
>
> The point (as I see it) is that just as client code can vary storages,
> storage can serve different clients.

Sasa,

There is a fundamental, foundational concept to grasp here, that is easily obscured by the excessive verbiage. But unless you get this foundational point, you won't be able to follow the arguments of the c.d.t. people at all. So I'll simply present it in isolation.

  A DBMS is not "storage." A DBMS is a system that manages   data, where "manages" describes a whole host of high level   facilities.

The c.o. people's arguments are mostly based on the false premise that a DBMS is a kind of storage mechanism. Once you accept a false premise, you can prove anything.

Now let us reconsider your question in light of the idea that a DBMS is not storage.

> The point (as I see it) is that just as client code can vary storages,
> storage can serve different clients.

Now we see that this statement, while it may have some value is certain contexts, does not apply when we are discussing DBMSs. Hence it is neither true nor false relative to the current discussion; it is simply talking about something else.

HTH Marshall Received on Fri Jun 02 2006 - 12:17:59 CDT

Original text of this message

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