Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
Date: Thu, 8 Jun 2006 13:25:41 +0200
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