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

On May 3, 2:30 pm, "Brian Selzer" <b..._at_selzer-software.com> wrote:
> "David Cressey" <cresse..._at_verizon.net> wrote in message
>
> news:6ui_h.5979$YW4.662_at_trndny06...
>
>
>
>
>
> > "Cimode" <cim..._at_hotmail.com> wrote in message
> >news:1178174344.866049.272810_at_h2g2000hsg.googlegroups.com...
> >> On 2 mai, 21:47, paul c <toledobythe..._at_oohay.ac> wrote:
> >> > Cimode wrote:
>
> >> > ...
>
> >> > > Brian,
>
> >> > > Don't you think you are overcomplicating things?
>
> >> > I certainly do. RT isn't as complicated or subtle as this thread is
> >> > making it out to be.
> >> I was not thinking about *subtleness*. I am having trouble following
> >> Brian's wordy line of thought. I am not sure he and I have do not
> >> have the same perception of what logical and physical independence
> >> is. I was also refering to terms I am not familiar with such as
> >> *database state*. To me they are totally foreign to RM formal
> >> theory.
>
> >> Maybe you could clarify. Thanks.
> >> Regards...
>
> >> [Snipped]
>
> > I think that "state" is a fundamental concept in computing. As such,
> > Brian
> > and others ought to be able to use it to communicate rather precisely,
> > without needing to present a formal definition. If you know what a
> > "database" is and you know what a "state" is, I think you know what a
> > "database state" is.
>
> > Having said that, I'll admit that I'm often lost by Brian's argument. He
> > seems to be arguing that transaction atomicity is an undesirable feature
> > of
> > our data model. If I'm reading that right, I abandon the effort to
> > understand the rest of what he's saying.
>
> I'm not sure which argument you're referring to. Several have arisen. I'll
> try to state them consisely:
>
> 1. assignment is bad: it breaks one of Codd's rules, unless you use
> surrogates, which breaks another of Codd's rules. Use a set of inserts,
> updates, and deletes instead.
In what does a correctly implemented surrogate key break Codd's rule. One could consider that there is no such thing as a natural key. At some point, any natural key is indeed a surrogate key.

> 2. multiple self-joins are bad for performance: use a cursor to eliminate
> them and thus improve performance.
What performance? Could you be more specific.

> 3. in a closed world, there is no such thing as "missing information."
Finally one thing I can decipher and agree on. So? Received on Thu May 03 2007 - 14:43:03 CEST