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

Andrew McDonagh wrote:
> frebe73_at_gmail.com wrote:
> >> It's not. I want the application to be isolated from the DB; and I
> >> want the DB isolated from the application. I wan't the application
> >> programmers to be able to change from Oracle to MySQL to Flat files.
> >
> > I think all here agree that in many cases, it is a good thing to be
> > able to switch between Oracle and MySQL. And all also think that the
> > all realizes that the best way to do this (if it is needed) is by using
> > a generic interface such as a JDBC driver and the use of ANSI SQL. Not
> > by writing custom interfaces for every application.
> >
> > But the big question that you repeatedly refuses to answer is why you
> > possibly want to change from Oracle to flat files? Don't you think that
> > a major design flaw is made if you start using Oracle and later
> > discover that the same thing could have been by flat files? Using
> > Oracle to emulate flat files is a little bit overkill. And emulating
> > Oracle using flat files would be a little bit hard.
> >
> > Fredrik Bertilsson
> > http://frebe.php0h.com
> >
>
> Maybe I'm missing something, but cant you see it was an example of 'change'.

Sure it's an example of change. A really bad, really misguided example of change, and one that necessitates some disastrously stupid behavior. And one that no one who understood what a dbms is would propose.

> Granted, not a particularly likely occurring example for software
> written for in house use where a certain DB vendor is already standard -
> its just an example.
>
> Robert M could easily have said '...able to change from Oracle to MySql
> to a Wax Drum...'

What if he said he wants to be able to change between an OOPL and an abacus? Hey, it's just an example of change; the specifics don't matter. Granted, it's not a particularly likely occuring one; it's just an example.

You should really be sure to isolate, in your application, any aspects of its architecture that assume an OOPL. An OOPL is a method for doing arithmetic, and you ought to be able to swap in any other mechanism for doing arithmetic at any time, like an abacus or one of those little solar-powered four function calculators that they give away at trade shows. Don't use any features like classes or virtual methods. Fortunately you won't need to because the only thing anyone should use an OOPL for is to add, subtract, multiply, and divide.

C++ and Java both have arithemetic built in to the syntax. Therefore, every OOPL does, and if something doesn't, it's not an OOPL. Also, that's the proper role of an OOPL: to add, subtract, multiply, and divide.

In the above two paragraphs, if you substitute OOPL with RDBMS, arithmetic with persistence, and abacus with flat file, you get the argument for "decoupling" the application from the dbms.

> The example is pointing out that Robert and Co's desire is to have an
> application design which is DBMS neutral - the DBMS can be a Relational
> one, a Hierarchical one or even a Quantum one built to use Wax Drums as
> the physical storage mechanism.

Again! "the DBMS can be a relational one ... as the physical storage medium."

What am I to make of the fact that, over and over again, I've pointed out that a dbms is not a physical storage mechanism, and yet I continue to hear arguments based on the false premise that it is? What hypothesis is left to me other than the Bob Badour Memorial Cognitive Deficiency Hypothesis?

> Can we forget the what the change is to - its not relevant for the
> discussion, its the desire to be able to change thats key.

No, we cannot forget. Yes it is relevant.

Marshall Received on Sat Jun 03 2006 - 01:45:30 CEST