Re: Mixing OO and DB

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

How about a specific example. But two pre-comments about that anyhow:

1. It is possible to include graph traversal in query languages. Some vendors provide such to various extents.
2. Functions are often sufficient to create a task-specific nodehopping sub-language for traversal (if vendor not provide it). OOP is usually overkill.

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

Indeed. And over-complicated wrappers that merely translate back-and- forth between high-level paradigms instead of add something new can create more dependencies that have to be managed, hindering such a goal.

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

You keep saying this, but it rings just as hollow as it did the first time. They do NOT change for signif different reasons in my experience. Yes, sometimes there is a schema overhaul, but they are rare enough that mass wrappers to hide such are overkill. Bloated wrappers slow down just about EVERY change, while schema overhauls happen about once every 15 years on the average. The ECONOMICS of your claims are suspect. Would you want to pay 15% extra tax every year, OR pay a 40% tax only once every 15 years? You are exaggerating the frequency of certain events. I've seen what I've seen and you cannot rip that from my bank of experience. (A shop that overhauls schema's every 3 years is either growing at above Google rates, or is foobarred.)

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

I've heard heavy users of ORM's agree that vendor-swapping is *not* the main reason nor benefit of using ORM's; that vendor-swapping would impact ORM-based systems also fairly heavily, partially due to the extensive performance tuning needed for such systems. (Yes, this is anecdotal info.) They use ORM's because they want an OO-centric view of stuff, NOT db vendor hiding.

>
> Sincerely,
>
> Patrick
>

-T- Received on Wed Mar 26 2008 - 17:06:50 CET