Re: A new proof of the superiority of set oriented approaches: numerical/time serie linear interpolation

"Cimode" <cimode_at_hotmail.com> wrote in message news:1177863186.258396.136950_at_y5g2000hsa.googlegroups.com...
> On 29 avr, 16:21, "Brian Selzer" <b..._at_selzer-software.com> wrote:
> > I would have done it differently. I would have used a cursor to
generate
> [Snipped]
> I respectfully think you miss the point of the entire thread.
> Thinking procedurally (use of cursors) is inherently inferior to set
> oriented approaches independently of a specific implementation and
> regardless of how one defines performance as response time, ability to
> run well in concurrent query environment and so forth.
>
Agreed.

The point I got from your remarks is that set oriented approaches are superior, not principally due to run times, but due to inherent solidity of the code. The gap between intent and expression of algorithm is often much less with set oriented approaches, and I believe you have illustrated this in the case in point.

Many times, those who wish to cling to procedural ways of doing things latch onto processing time as their reason for rejecting a set oriented approach. They are usually wrong, sometimes dramatically wrong. I'm reminded of a case in this newsgroup where someone (sorry, I forget who) reduced the "weekend update" time from 45 hours to 45 minutes by recoding thousands of lines of procedural code in about 300 lines of SQL.

I've seen the same "speed" arguments used for avoiding views, and avoiding logical data independence generally. Also used to defend the "one big table" design as opposed to normalized, or even mostly normalized design.

>
> > I would bet the process would run much faster than your solution. In
rare
> > cases, cursors can actually increase performance.
> I don't think one can establish that for a certainty.
> If you ask me I tend to think that even in direct image systems, set
> oriented are superior because they give less time outs in highly
> concurrent environment. I had the opportunity to take away several
> hundred cursors based processes that would run faster on development
> environments but would totally time out in heavy load environment. I
> have not encoutered so far any cursor based solution that was not
> imposed by a poor design. And I have not found any satifying cursor
> based solution. Often the use of cursor and (procedural) dictates
> unacceptable tarde off where evrything is given up for reponse time
> sake...
>

Strongly agreed.

> One should keep in mind that response time is only one of several
> criterias that may define performance. Defining performance only
> according to response time is simply a consequence of using poorly
> designed direct image systems.
> [Snipped implementation specific diret image internals]
>
> > I generally don't advocate the use of cursors, but sometimes the
optimizer
> > just isn't smart enough to generate what I know to be a minimum plan, so
in
> > those cases I use them.
> Speaking of optimizers in the case of direct image systems is like
> asking a cow to run a race. Only a TRDBMS that would correctly
> separate logicala and physical could inherentlyy allow optimization.
>
>
> Regards...
>
Received on Sun Apr 29 2007 - 21:29:39 CEST