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

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Sat, 03 Jun 2006 08:29:08 +0200
Message-ID: <44812bc7$0$31651$e4fe514c@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?

One key facility would be the /sharing/ of data; between instances of applications (persistence can be viewed as a specific case of this: sharing between subsequent incarnations/runs), but also between different applications.

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

Why not? Simply serializing/deserializing all objects (like smalltalk did - the "system image") to a file on secure media gives you perfect persistence. That you want more shows that you already are aware of some desiderata beyond just that.

> 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 - 01:29:08 CDT