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

Robert Martin wrote:
> In an enterprise there is a large body of interelated data. This data
> needs to be kept in one place, and in one form, in order to eliminate
> duplication and maintain integrity.
>
> In an enterprise there are many different applications. Each
> application needs to manipulate a portion (or "view") of the data.
> Very few applications need to maniuplate ALL the data.
>
> 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. Presumably having a "localized structure" requires a mapping layer (enterprise <-> local). If that layer is trivial, then it can be expressed in terms of the enterprise data anyway, and hopefully with such mechanisms as Views.

If it's complex, then either the application lacks the ability to read and manipulate the enterprise "structures," or it's a specialized tool. Reports, batch programs, GUIs, etc. can all typically access at least SQL DBMSs.

Maybe I'm misunderstanding what you mean by "optimum structures" and how they relate to the enterprise data?

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

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

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

• erk