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

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- -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 Received on Wed May 31 2006 - 22:25:24 CEST