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

From: Sasa <>
Date: Fri, 02 Jun 2006 20:39:14 +0200
Message-ID: <e5q0k8$1si$>

Marshall wrote:
> 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.

So can you list some short but specific keypoints - what are these 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.

I am very far from being DBMS expert, so I offer following statement, fully aware of my ignorance. While I regard DBMS primarily as a storage, I also use it to perform rich queries (which obviously cannot be performed as easily in for example flat file), enforce integrity and security.

The features listed are still very related to the "storage" as I see it from my little OO world, so I refer to my first question, what is that host of high level facilities?

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

I could agree, providing that the already mentioned "host of high level services" includes something dramatic which would force me to move my domain logic (combined data and behavior) to SQL.

In my statement, I was trying to accentuate the need for loose coupling between client and DBMS.

Given the fact the DBMS can serve more apps (but actually even one can mean trouble if SQL code is spread around the app code), and given the fact that one app might want to switch DBMSes I think it would be smart to decouple both as much as possible, which to me means no client code in DBMS, and very localized DBMS specific statements in client code. Now I'm interested with what part you DBMS guys (no irony, or offense meant) disagree and how do you envision it?

Sasa Received on Fri Jun 02 2006 - 20:39:14 CEST

Original text of this message