Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
Date: Tue, 13 Jun 2006 13:32:23 +0200
On 2006-06-01 22:37:48 +0200, "erk" <eric.kaun_at_gmail.com> said:
>> The optimum structure for each application is local to it's particular
> 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.
>> 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.
> 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 - 13:32:23 CEST