Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
Date: Wed, 31 May 2006 09:12:16 -0500
Message-ID: <2006053109121622503-unclebob_at_objectmentorcom>
On 2006-05-30 17:54:53 -0500, "Marshall" <marshall.spight_at_gmail.com> said:
> CMCC wrote:
>> Marshall wrote: >> >> I speak in terms of what he *seems to have written*. Somehow I have >> to refer to what it is I am talking about! And that is the subject of >> this thead.
>
> Grrrr. Okay, fine; I'll do the work. In the future if you have a
> question
> for me, it will be necessary to ask me the full actual question, and
> not refer ambiguously to things written elsewhere.
>
> [scanning back through the thread ...]
>
> Okay, maybe you are asking about this:
>
>> No, a DBMS is a bucket of bits with some low level rules to manage >> those bits. An OO application provides the beavior that the customer >> wants to see. We can completely eliminate the DBMS and replace it with >> another of an entirely different form (non Relational for example) and >> still have all the business behavior we need. >> The people who sell databases have sold you, and the industry, a >> misconception: that the database is the heart of the system. This is >> flawed. The heart of the system is the application code. The database >> is a detail to be decided at the last possible moment and kept in a >> position so flexible that it can be swapped out for another at a whim.
>
> There are many different contexts in which software is developed.
> I will speak relative to enterprise software, which is where DBMS
> software is often found. In that context, the above quoted
> paragraph is pure, unadulterated garbage. It is not simply
> valueless; it is actively harmful. The writer furthermore
> demonstrates that he completely lacks any understanding
> of what the field of data management is, or what it is for,
> or why it is useful.
Ah, it is so easy to generalize about what one person understands. Are you saying that it is "pure unadulterated garbage" that application developers should isolate their application code from the the whims of the API designers at Oracle? Should those application designers use every little cute ORACLE trick and call? Or shoudl they stick to standard SQL as proferred by ODBMS or JDBMS, etc. Should those application developers scatter embedded SQL all through their application code? Or should they partition that application code into areas that know about the DB and areas that don't? Should they strive to make it possible to swap Oracle for MySql or not? Should they strive even to eliminate the relational flavor of the data from the guts of their algorithms, or not.
> The reason why you see crap like this is because it is being
> written by application developers. Application developers are
> great at writing applications, but once they have success in
> that one area, they overgeneralize and begin to believe that
> their techniques are the correct techniques to apply to every
> software development area. However this represents a
> multi-decade regression in the field of data management.
I agree with some of this. Much of this debate comes from one side not understanding the position of the other, and overgeneralizing. However, I understand both sides quite wall, having done both and been resonsible for both, for damned near 35 years now. I also agree that my "pure unadulterated garbage" above was spoken from the point of view of an application developer. The reason for that, of course, is that it was in response to database developers overgeneralizing their own point of view.
> Data management in the 1960s lacked any understanding
> of the issues that the field has today. And if the application
> programmers have their way, and the existing field of
> data management is discarded, those same application
> programmers will face all the same problems that the
> programmers of the 1960s did, over again. And over
> the decades, they'll build systems that tackle questions
> like integrity enforcement, ad hoc queries, transaction
> management, etc. Slowly, they will reinvent the field.
It is actually not a bad thing that one side is forced to reinvent the other, Indeed that may be the only way for the two sides to see eye-to-eye. For, of course, the inverse operation is occurring on the other side of the divide. Database application developers are slowly learning what software application developers have fought long and hard to learn over the last 30 years. That coupling and cohesion matter, and that partitioning, data hiding, and isolation are necesary for large applications.
> And, if they do so, it would be poetic justice if the
> programmers being born today trash all their work
> in favor of some new fad.
-- 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 Wed May 31 2006 - 16:12:16 CEST