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

On May 2, 11:05 am, "David Cressey" <cresse..._at_verizon.net> wrote:
> "Cimode" <cim..._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]

David,

Pleas ignore CELKO's comment and do not encourage him in further discussion. After suggesting to change the started given hypothesis about the problem (discussing the design - off topic to the question) and inducing OLAP to a debate about logical interpolations and the way they are applyable logically in RM, he show once more demonstrated he has no clue about RM. Received on Wed May 02 2007 - 12:17:22 CEST