Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

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 11:22:47 +0200
Message-ID: <2006061311224716807-unclebob@objectmentorcom>


On 2006-06-01 22:26:02 +0200, "Mikito Harakiri" <mikharakiri_nospaum_at_yahoo.com> 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.

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.

-- 
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 - 04:22:47 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US