Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
From: Andrew McDonagh <news_at_andmc.com>
Date: Sat, 03 Jun 2006 08:27:01 +0100
Message-ID: <e5rdkd$f7c$1_at_news.freedom2surf.net>
>
> 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.
>
>
>
> 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.
>
>
>
> Again! "the DBMS can be a relational one ... as the physical storage
> medium."
>
> No, we cannot forget. Yes it is relevant.
>
>
Date: Sat, 03 Jun 2006 08:27:01 +0100
Message-ID: <e5rdkd$f7c$1_at_news.freedom2surf.net>
Marshall wrote:
> 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."
I didn't write ' the dbms is a physical storage mechanism' I wrote that a custom dbms could be made to use quantum physics AND its state could be persisted on a Was Drum.
DBMS and persistence are two different things.
>
> 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.
>
>
I disagree. YMMV
> Marshall
>
Received on Sat Jun 03 2006 - 09:27:01 CEST