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@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 - 02:27:01 CDT