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

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Thu, 01 Jun 2006 23:45:35 GMT
Message-ID: <z_Kfg.16280$A26.376787_at_ursa-nb00s0.nbnet.nb.ca>


Joe Van Dyk wrote:

> Marshall wrote:
> 

>> Joe Van Dyk wrote:
>>
>>> Mikito Harakiri wrote:
>>>
>>>> Robert, you claim 35 years of application programming experience. Have
>>>> you ever come across a performance problem when database is accessed
>>>> via API
>>>>
>>>> getItemIdList
>>>> getItemDetail
>>>>
>>>> so that a single jsp page issued a hundred SQL statements instead of a
>>>> single one? Come on, this one is so common that it surfaces on every
>>>> performance meeting.
>>>
>>> This problem is easily solved via caching.
>>
>> This is like saying: we have a big pile of dirt on our expensive
>> Persian rug; what shall we do? That problem is easily solved
>> by covering the dirt in a layer of palm fronds.
>>
>> Caching certainly has its place in the set of tools used
>> to solve performance problems. And its place is exactly:
>> the tool of last resort. When everything else has failed,
>> you cache. I don't know why it's so often the *first* thing
>> that junior programmers come up with; maybe because
>> it's easy to understand, and solving the actual problem
>> requires some effort.
>>
>> The *best* way to solve the performance problem that
>> Mikito describes is to rewrite the object-at-a-time code
>> into set-at-a-time code, which will necessarily perform
>> much faster. Unfortunately OOPLs encourage object-
>> at-a-time thinking, so it's hard for OO programmers to
>> learn this lesson. I try to repeat it at every team
>> meeting, which is not usually a problem because
>> somewhere in every meeting someone will propose
>> papering over a performance problem by caching.
>>
>> Marshall
> 
> I think the *best* way depends on the particular issue at hand. However, 
> I don't possess the mental aptitude necessary to make blanket statements 
> about what's best for all web applications.
> 
> In RubyOnRails, I probably would create a instance variable in the 
> Controller that contains the data from one SQL statement (perhaps 
> automatically generated in the Model), and use that data in the view. 
> I'm sure that's horrible and won't work.  All those applications out 
> there that I've written are probably busy crashing and corrupting data, 
> as I'm using objects and escapulation or something.

False dichotomy is fallacious reasoning. If your programs crash, I suggest it has more to do with the way you reason than what tool you used. Received on Fri Jun 02 2006 - 01:45:35 CEST

Original text of this message