Re: Mixing OO and DB

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.

 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.

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.

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

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

 From implementation, not from the schema.

--
What you see depends on where you stand.