Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
Date: 13 Jun 2006 06:08:35 -0700
> 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.
What are the forces to change databases that would not also force you to change the application?
> 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.
I am not sure about your definition of "application". But in many cases there are only one application using a databases or multiple applications that all share common domain objects, that will couple that together anyway.
> 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.
Using views maybe?
> 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.
http://moonbird.sourceforge.net Received on Tue Jun 13 2006 - 15:08:35 CEST