Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
Date: Fri, 02 Jun 2006 20:39:14 +0200
> 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
> 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 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.
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