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

From: Robert Martin <unclebob_at_objectmentor.com>
Date: Thu, 8 Jun 2006 13:25:41 +0200
Message-ID: <2006060813254143658-unclebob_at_objectmentorcom>


On 2006-05-31 21:45:26 +0200, Bob Badour <bbadour_at_pei.sympatico.ca> said:

> Robert Martin wrote:
>

>> On 2006-05-31 09:32:34 -0500, "Marshall" <marshall.spight_at_gmail.com> said:
>> 
>>> Would you also say that the decision of whether to use an OOPL
>>> or an FPL is a detail? If your system does data management,
>>> then at the core of the system you should have a Data Base
>>> Management System. Not to use the tools best suited for
>>> the problem is irresponsible.
>> 
>> I certainly agree with the last part of that.  I'd also say that the 
>> decision not to use an OOPL had better be very well founded.  (e.g. 
>> like you are working in a DSP that has no OO compiler).

>
> Or you are working on an application that doesn't need to use a very
> large state machine or you need the competitive advantage offered by a
> more-powerful higher level language than the typical OO language.

I'm not sure about the state machine remark; but I agree that there are special domains in which special purpose language are more appropriate than a general OO language. I also think that for simple form/db based apps, a DB language makes a lot of sense. But the more general purose the application, the more interesting an OO language becomes for managing the complexity.
>
>

>> If you system does data management then you need some way to manage that data.

>
> Duh! And the best way we have to manage data is with a relational
> database management system.

Some data, yes. But just as special purpose domains do better with special purpose languages, they also sometimes require special purpose data management.

Relational databases are very good at extracting large amounts of data using a few specific queries. They are not particularly good at extracting small amounts of data using many queries. For example, they are not particularly good at quickly managing and traversing graphs or trees.

> You also need some way to transform that data according to the
> application business rules.

> Here, once again, you prove your ignorance and stupidity.

What a shame. I thought we had dispensed with talking and thinking about people instead of ideas.

> The business rules are the business rules. One does not have a separate
> set of rules for applications from data. Everything has to meet the
> needs of the business.
>
> Transforming data according to the business rules is best done as close
> to the level of intent as possible using the most powerful tools
> available for deriving data. Those tools are equivalently the
> relational algebra and the relational calculus.

I agree with everything you said except for the generality of the last sentence. There are application domains in which the statement is trivially correct. There are other application domains for which the statement is trivially wrong. And there are application domains for which the statement is arguable.

For example, would you use an RDBMS to gather the signals from NAVSTAR satellites and then calculate and plot your position on a NavTeq map?
>
> May be, but not bloody likely. Idiot.
>
> That's because you are stupid and ignorant.

Have you come yet?

-- 
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 08 2006 - 13:25:41 CEST

Original text of this message