Home -> 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_at_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 - 11:22:47 CEST












Original text of this message