Re: Mixing OO and DB

From: Patrick May <>
Date: Sat, 01 Mar 2008 10:08:38 -0500
Message-ID: <>

Marshall <> writes:
> On Feb 29, 3:33 pm, Patrick May <> wrote:
>> Marshall <> writes:
>> The fact that you don't understand it doesn't make it
>> impossible. One approach is the Dependency Inversion Principle.

>> The application code depends on an interface and one implementation
>> of that interface uses a relational database. The database schema
>> can change without impact to the application code because only the
>> implementation of the interface is affected. The relational
>> database implementation can be replaced with some completely
>> different mechanism that implements the same interface and the
>> application remains unaffected. Decoupling.
> Ten years ago I thought that sort of thing seemed a promising
> approach. Today, after having built many systems using this and a
> variety of other approaches, it is obvious to me why what you
> suggest requires throwing away most of the value of the RDBMS.

     What value in particular?

> For anyone who doesn't understand where most of the value of the
> RDBMS lies, it will be hard to understand my opposition. In fact I
> am sure that the me of ten years ago would think my opposition
> baseless!

     For some solution domains the relational model is a better fit. Others are more easily addressed with the OO model. Still others with the functional model. There is overlap where more than one can be used and even situations where more than one should be used. Are you claiming that the relational approach is always the best?

>> The general ledger schema is not the schema for the content
>> management application.
> Agreed. The general ledger schema and the general ledger
> application cannot be decoupled.

     Now you're just being a twit. It is very straightforward to decouple application logic from the mechanism used to maintain the persistent state of that system, even if that mechanism is a relational database and corresponding schema. Your attempt to create some kind of strawman and score rhetorical points is transparent and ridiculous.



S P Engineering, Inc. | Large scale, mission-critical, distributed OO
                       | systems design and implementation.
  | (C++, Java, Common Lisp, Jini, middleware, SOA)
Received on Sat Mar 01 2008 - 16:08:38 CET

Original text of this message