Re: Mixing OO and DB

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Fri, 04 Apr 2008 01:25:27 +0200
Message-ID: <47f5668a$0$14346$e4fe514c_at_news.xs4all.nl>

Patrick May schreef:

> mAsterdam writes:

>> Patrick May wrote:
>>>>> If the application implements the solution using a DAG, for
>>>>> example, and the state of each node in the DAG is stored in a
>>>>> relational database, then a mapping between the two models must
>>>>> take place.
>>>> The data is regrouped. Not a huge decoupling, but yes, more than
>>>> just aliasing.
>>> It's more than regrouping. A different set of behaviors (graph
>>> traversal, etc.) are being supported explicitly.
>> From the behaviour POV (point-of-view) there is some decoupling
>> (effort /and/ gain), but it is completely done within the
>> behavioural realm, not at the border (the schema). The set of
>> behaviours is not relevant to the data itself to begin with, so from
>> the data POV no decoupling is gained at all.

> 
> I think we might have the same disconnect that Mr. Selzer
> identified.  I am using the word "schema" to refer to both the data
> and the data structures that hold it.  Are you using that word to
> refer to the data only?

That is a loaded question. The schema, as seen from the application, describes data. It does use structures to do so. The structures holding the data, however, are invisible to the application.

>>>>> If the application changes the way it uses its internal model,
>>>>> that shouldn't have an impact on the schema.
>>>> There is no "should" or "shouldn't" here.
>>> Actually, there is. Managing dependencies is essential to
>>> creating maintainable software.
>> As you might have suspected by now, we are on complete agreement on
>> the general statement. What I am arguing is that there is a limit to
>> the level of decoupling achievable. It is impossible to decouple
>> from the data itself at the application level. Let me haste to add
>> that it /is/ possible to use libraries, (consider
>> e.g. data-structure organized libraries, amongst which are class
>> libraries), including those specifically built for use in this
>> application, within the application.

> 
> I believe we're mostly in agreement.  The decoupling I'm talking
> about is in terms of the data structures, not the data.  There can, of
> course, be other sources of data than a relational database.

Sure. However, they are irrelevant to the topic. So - no decoupling from the data, needed by the application, as described by (the application-relevant subset of) the schema.

>>>> As long as the application uses the same data, the change won't
>>>> impact the schema, and if there are changes in the data
>>>> requirements, it will. No design approach or tool-stack will help
>>>> you avoid the inevitable.
>>> True. However, the application and the database schema change
>>> at different rates and for different reasons. That's a good reason
>>> to decouple them.
>> Yes, no argument here. Please acknowledge the limits.
>>
>> It is predictable which changes necessarily impact both schema and
>> application: the ones driven by changes in the data-requirements.

> 
> Date requirements of the application, not of other applications
> that may use the same database.

Yes, exactly changes in the data-requirements of the application. Again: No approach, no toolstack influences that impact.

>>> Those techniques and general patterns like Dependency
>>> Inversion allow both the application implementation and the
>>> database implementation to be completely replaced without impact to
>>> the other component. That's decoupling.
>> From implementation, not from the schema.

> 
> It's decoupling between the two representations that hold
> overlapping subsets of the same data.

It looks like you are reluctant (less strongly than Dmitry, though) to acknowledge application-independent and representation-independent existence, meaning and value of data. Received on Fri Apr 04 2008 - 01:25:27 CEST