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

From: Marshall <>
Date: 13 Jun 2006 10:04:01 -0700
Message-ID: <>

Robert Martin wrote:
> On 2006-06-01 22:26:02 +0200, "Mikito Harakiri"
> <> said:
> > Robert Martin wrote:
> >> what's wrong with my assertion that application design should be decoupled
> >> from database design.
> >
> > Assertion alone is worthless without solid method that supports it. And
> > what method OO propellerheads suggest? OR mappers (which essentially
> > are reincarnated OODBMS)? What I am supposed to learn 20 something
> > ad-hock mapping types instead of 6 clean relational operators? Or worse
> > yet, some "pattern"?
> I agree that assertion is worthless without reason. So, here are my
> reasons, based on 30+ years of software development experience. (Which
> may be completely bogus because of what my great-god-father sang while
> welding panels on the Titanic)
> Databases are data centric. While they have behaviors; those behaviors
> are related to data management. Applications are behavior centric,
> while they manipulate data, the things that do to that data are rich
> with business rules and formatting behaviors.

I'm curious: do you have a definition of "behavior"? I hear this word a lot and I'm not sure exactly what is intended. Is a method behavior? Is a class behavior? What about a function? Is behavior a transformation of data? Wouldn't this make it a synonym for calculation?

> Behavior and Data have different constraints. Data must be usable by
> many different applications. Therefore the structure of the data must
> accomodate all applications, and cater to those that are most
> important. Changes to the database must be carefully considered so as
> not to break exsisting applications.
> Applications are generally independent of each other (altough they
> often communicate indirectly through the DB). Changes to applications
> have much to do with behavior and formatting, and not so much to do
> with data.
> Since the forces that change databases and applications are different,
> and their customers are different, they should be designed for these
> different environments and constraints. An application should be
> designed such that it's modules are flexible and easy to change. A
> database should be designed such that it's changes to it's structure
> minimize impact on all the applications.
> If an application depends strongly on the database structure, then the
> structure of its behaviors will be coupled to the database structure.
> Since this structure is a result of catering to many different
> applications, each application will have an indirect coupling on all
> the others. Or to say this a different way, the application will not
> be able to use the data structures that are most favorable to its
> algorithms because it is coupled to the DB whose data structures are a
> compromise between all applications.
> If, on the other hand, the applications are designed to be independent
> of the database structure, then the applications can use whatever data
> structures are appropriate for their algorithms.

Here, especially in this last paragraph, I don't see that you're making sufficient distinction between physical and logical structure. Much/all of my disagreement with the above stems from trying to apply this line of reasoning to logical structure. It just doesn't makes sense that way. However, applications ought to be able to use whatever physical structure best suits their needs.

It is unfortunate that most programming languages have little or no support for separating physical and logical concerns.

Marshall Received on Tue Jun 13 2006 - 19:04:01 CEST

Original text of this message