Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

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

From: Marshall <marshall.spight_at_gmail.com>
Date: 1 Jun 2006 16:47:33 -0700
Message-ID: <1149205653.207944.145880@i40g2000cwc.googlegroups.com>


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.
> >
>
> 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.

You misunderstand. I was only referring to the specific class of problem that Mikito mentioned.

> 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.

To the extent that I understood what you said, it sounds like you are saying you'd do the specific thing that I was proposing as a solution. So I don't see where we have any disagreement.

> 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.

It is entirely possible to write useful apps in OOPLs that access databases. It's what I do for a living.

There are good ways and bad ways to go about it, of course ....

Marshall Received on Thu Jun 01 2006 - 18:47:33 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US