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

From: David Cressey <cressey73_at_verizon.net>
Date: Wed, 02 May 2007 10:05:04 GMT
Message-ID: <knZZh.7332$Hd1.4196_at_trndny07>


"Cimode" <cimode_at_hotmail.com> wrote in message news:1178053090.386865.126950_at_h2g2000hsg.googlegroups.com...
> On 30 avr, 13:42, "David Cressey" <cresse..._at_verizon.net> wrote:
> > "Cimode" <cim..._at_hotmail.com> wrote in message
> [Snipped]
>
> > > 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.
> >
> > I am not sure I understand your point. If I got it right, I'd like to
> > suggest that procedural oriented thinkers like to superimpose an order
> > requirement on the actual requirements in order to force a strategy that
> > they know (rightly or wrongly) to be superior to the one chosen by the
> > optimizer in the absence of ordering directives.
> >
> I realize I missed that point but the answer is yes. That's what I
> meant to say.
>
> I would also add to the bill of procedurally inclined programmer the
> *physical bias* to create overhead objects (temp tables, additional
> columns) in order to meet the requirement of a procedural approach.
> We have one example here. For instance, the immediate instinct of
> dear Brian was to create additional columns and objects (+ unecessary
> operation) where none was in fact necessary. Procedural approaches
> produce both physical AND logical overhead. What can be done in 3 set
> operations may require much more operations in procedural mindset (out
> of itterations I don't count).

Well, I'm going to plead guilty, myself, on this count. I don't suffer from the same opinions as Brian does concerning intermediate states. My tendency to create additional constructs that are theoretically unnecessary comes in the area of data warehousing and data marts.

I've argued in favor of the star schema approach in more than one thread going back a year or more. A star schema materializes a view of the data that looks different from a normalized view. I like star schema for some very practical reasons.

But it's clear to me, off the top of my head, that one could achieve the same results without actually materializing the star, but merely translating, on demand, queries against the star back into corresponding queries against the normalized data. I still don't recommend doing that, however.

>
> [Snipped]
>
>
Received on Wed May 02 2007 - 12:05:04 CEST

Original text of this message