Re: Mixing OO and DB
Date: Thu, 03 Apr 2008 16:47:56 -0400
mAsterdam <mAsterdam_at_vrijdag.org> 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?
>>>> 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.
>>> 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.
>> 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.
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation. pjm_at_spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)Received on Thu Apr 03 2008 - 22:47:56 CEST