Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
Date: Sat, 03 Jun 2006 08:29:08 +0200
Message-ID: <44812bc7$0$31651$e4fe514c_at_news.xs4all.nl>
Sasa wrote:
> 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.
To paraphrase Einstein: as loose as posible, but not looser.
> 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
"no client code in DBMS" - could you give an example of what you'ld consider typical client code?
> I'm interested with what part you DBMS guys (no irony, or offense meant)
> disagree and how do you envision it?
I'm not fond of the us vs. them approach - but I am a c.d.t. regular. Received on Sat Jun 03 2006 - 08:29:08 CEST