Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

From: Robert Martin <unclebob_at_objectmentor.com>
Date: Tue, 13 Jun 2006 13:32:23 +0200
Message-ID: <2006061313322384492-unclebob@objectmentorcom>

On 2006-06-01 22:37:48 +0200, "erk" <eric.kaun_at_gmail.com> said:

> Robert Martin wrote:

>> The optimum structure for each application is local to it's particular
>> function.

>
> While I agree that data and behavior will never be unified, you lost me
> here. Maybe I'm misunderstanding what you mean by "optimum structures" and
> how they relate to the enterprise data?

Imagine a circuit emulation application. It reads the circuit from an RDB in the form of many interlinked rows across many tables. Many separate queries are needed because each row contains the keys of other rows to create a graph of components and connections.

Once we have read the whole structure in, we have to emulate it. This requires a tranformation of the data into matrices so that we can solve the circuit equations.

Next, we'd like to draw a graph of the voltage on a set of signals over time. This requires yet another data structure related to the circuit.  (One that will likely never be placed in the DB BTW).
>

>> the optimum structure for the data has to do with ALL the applications.
>> The structure of the data must make affordances for the most important
>> applications, generally at the cost of inefficiency for those
>> applications that are infrequent or less important.

>
> Are you talking about denormalization in the enterprise database?

No, I'm just saying that the structure of the enterprise data is a compromise over the optimum structures for all the applications that use it.

> The
> most important applications are typically (at least in my experience)
> those on the front lines with many users, and I don't often see a need
> for them to deal with overly-localized "data structures".

I agree that there can be applications for which the structure of the enterprise data is appropriate.
>

>> So, the design trade-offs for the applications are completely different
>> from the design trade-offs for the data model.  Therefore unifying them
>> is probably impossible.

>
> The only one you've mentioned is efficiency, and both applications and
> data model share some big concerns: concisely expressing business
> requirements, sharing data between applications, having a common types
> and business predicates, etc. I still don't see that a normalized
> database is only of value from the point of view of the database; it
> has a large impact on applications as well.

Agreed. Normalization also has certain inconveniences (e.g. no embedded arrays) that application programmers often step around by reformating the data.
>

>> To defend themselves developers export behavior out of the OODB and
>> into the applications.  Eventually the OODB is denuded of behavior and
>> becomes little more than a network database -- a pile of interelated
>> data structures.  At which point it might as well be an RDB.

>
> Except with an RDB you've have a lot more than a castrated OODB - cum -
> network DB.

Agreed. I'm not trying to defend an OODB. I'm demonstrating that data and behavior tend to separate over time because some application don't want the behavior that's bound to the data.

-- 
Robert C. Martin (Uncle Bob)  | email: unclebob_at_objectmentor.com
Object Mentor Inc.            | blog:  www.butunclebob.com
The Agile Transition Experts  | web:   www.objectmentor.com
800-338-6716                  |

Received on Tue Jun 13 2006 - 06:32:23 CDT