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

On 29 avr, 21:29, "David Cressey" <cresse..._at_verizon.net> wrote:
> "Cimode" <cim..._at_hotmail.com> wrote in message
[Snipped]
> 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.
Not only. I have not talked about *order*. Set oriented approaches are totally *order insensitive* in the sense they never require some kind of order as a prerequisite.

> 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.
Until they have slow disks and can not solve CPU bottlenecks anymore through more CPU power. A recurring problem in modern systems.

[Snipped]
> 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.
If you ask me, I think the *speed obsession* comes from the good deal between poor software editors and hardware manufacturers. The rest is just a consequence of cookbook approach.

> > > 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 Mon Apr 30 2007 - 08:07:49 CEST