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

From: Robert Martin <unclebob_at_objectmentor.com>
Date: Thu, 1 Jun 2006 15:05:10 -0500
Message-ID: <2006060115051023810-unclebob@objectmentorcom>

On 2006-05-31 09:45:00 -0500, "Marshall" <marshall.spight_at_gmail.com> said:

> Robert Martin wrote:

>> 
>> I disagree with this analogy.  The RDBMS is a mechanisms for storing,
>> accessing, reporting, data.

>
> If your understanding of the role of the DBMS only extends that
> far, then no wonder you misunderstand so much.
>
> Storage is an incidental feature of a DBMS. A thing can be
> a DBMS and not do persistence.
>
> Your use of the word "access" again reinforces the idea
> that you view the DBMS as merely a storage mechanism.
>
> That you completely fail to mention the *primary* uses
> of a DBMS is telling. Structure, integrity, and manipulation
> are the central strengths of a DBMS. The pride of
> application developers (or simply their lack of education)
> makes them want to reserve these functions for their
> application code, because that's the only hammer they
> know how to swing well. But application code is an
> inferior tool for these.

Dear Marshall,

The soft insinuation that I am ignorant, is really just an ad-hominem argument. The gentle implication that I am part of an arrogant and ignorant group is also an ad-hominem. I encourage you to avoid such arguments since you are quite completely ignorant of my knowledge of the subject.

In the midst of the ad-hominems I think you made a good point. I did, in fact, underlay the role of the DBMS. I don't think you followed through on that point though. In what way does the importance of the DBMS impact on my assertion that the application design should not know about the details of the DBMS. Do the attributes of data integrity and manipulation mean that the application code should strongly couple itself to the details of the DBMS?

>> That mechanism can be implemented many
>> different ways and need not even be an RDB.  The application code
>> defines what the program does with the data.

>
> It appears that the OOPL mantra of "state and behavior" has
> gotten you to the point of believing that data structures and
> imperative functions are the only way to work with a computer.
> You may wish to consider the possibility that this is a very
> limiting, perhaps even stunting way to look at the world.

I'm an old hand at many different languages and programming schemes. Along with all the standard application languages, I've studied and used languages like Prolog, Forth, Snobol, etc, etc, etc. I drew my first ER diagram over 20 years ago, when I already had 15 years of exeperience behind me, and have since used many different RDBs, in many different environments. I have designed reactive systems driven by triggers, and I have designed imperative systems driven by top down functions. I have worked in MIS environments and embedded real-time environments. I have worked on shrink-wrapped software, and mathematical modeling software.

In short, if my way of viewing the world is "stunting" it is not because I haven't been learning as much as I can about as much of this industry as I can for the last 35 years.

Oh and by the way, that last paragraph was also a subtle ad-hominem argument about what "it appears" my opinions might be and how they might be stunting.

SO.......

Let's see if we can drive this back to substance. Instead of telling me all the things that are wrong with my upbrining, tell me what's wrong with my assertion that application design should be decoupled from database design.

-- 
Robert C. Martin (Uncle Bob)  | email: unclebob_at_objectmentor.com
Object Mentor Inc.            | blog:  www.butunclebob.com
The Agile Transition Experts  | web:   www.objectmentor.com
800-338-6716                  |

Received on Thu Jun 01 2006 - 15:05:10 CDT