Re: Mixing OO and DB

From: mAsterdam <>
Date: Sat, 29 Mar 2008 14:33:21 +0100
Message-ID: <47ee44c6$0$14352$>

Patrick May wrote:
> 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.

>> Barring design flaws, your examples deals with two applications
>> using the same data: the one that deals with the individual nodes
>> and the one that deals with the DAG as a whole. Should changes in
>> the individul node states outside the influence of the current
>> application be reflected in it? Not a big decoupling, yet there is
>> already a price-tag.

> Depending on the transactional context, it may be necessary to
> update the application state based on database changes.

We already have more specific knowledge already: If (and only if) the change is relevant to subsequent actions within the context of this instance of the running application, the application state needs to reflect the mutations of the data in the database. In that sense the application only borrows the data.

> Even if it
> is, there is a large benefit to having a representation that is more
> expressive in the context of the application's solution domain.

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

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

>>>>> application can be decoupled from the schema.  You are suggesting
>>>>> using views to do so.  That's one possible mechanism.  OO
>>>>> languages provide others.
>>>> Which?
>>>      ORM tools, DAOs, and caches, for example.  
>> These provide decoupling in names, shape and actuality of the data.
>> I would not call that decoupling from the schema - the schema still
>> describes the data itself. Is that the whole problem? Labeling
>> something as decoupling or not?

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

What you see depends on where you stand.
Received on Sat Mar 29 2008 - 14:33:21 CET

Original text of this message