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

From: David Cressey <>
Date: Tue, 13 Jun 2006 11:41:38 GMT
Message-ID: <Svxjg.1564$s84.12_at_trndny03>

"Robert Martin" <> wrote in message news:2006061311224716807-unclebob_at_objectmentorcom...
> 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
> >> 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.
> 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.

The above is pretty good. for the most part, I agree.

One thing I would add is that an enterprises manages its own data, in one way or another. The enterprises who manage their data well will have a competitive advantage over similar enterprises that manage their data poorly.

One path to poor data management is the purchase of an outside package that performs the functions of some part of the eneterprise, presumably well, but isolate that part of the eneterprise from enterprise wide data sharing.

A lot of the people who specialize in programming work for people who build packages for sale. This creates a bias against the real data management needs of their clients. Ultimately, a lot of the debates between people who feel that behavior should rule and those who feel that data should rule are a matter of perspective. It depends on whether you view the enterprise as something you manage or as a client you sell deliverables to. Received on Tue Jun 13 2006 - 13:41:38 CEST

Original text of this message