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

"Brian Selzer" <brian_at_selzer-software.com> wrote in message news:VBk_h.20774$Um6.2594_at_newssvr12.news.prodigy.net...
>
> "David Cressey" <cressey73_at_verizon.net> wrote in message
> news:6ui_h.5979$YW4.662_at_trndny06...
> >
> > "Cimode" <cimode_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.
>

I'll agree up to a point. I don't agree that "assignment is bad". I will agree that
assignment is not a substitute for inserts, updates, and deletes.

> 2. multiple self-joins are bad for performance: use a cursor to eliminate
> them and thus improve performance.
>

It depends. Cursors are not the entire algorithm. The process that uses the cursor output can (and frequently does) burn more resources than the extra reads occasioned by a declarative approach. This depends on the computing/DBMS environment one uses.

> 3. in a closed world, there is no such thing as "missing information."
>

In the real world, databases are often an imperfect image of the real world they are supposed to represent. surely you wouldn't argue that a real world database would be of no value if it were missing one row in a table that intended to follow the closed world assumption.

It's the classic, "we can't admit you as a patient, because you aren't in the database" syndrome. Bad, but you live with it until you can correct it.

If you are building stuff for the real world, you by golly have to do something intelligent with "missing information". Received on Thu May 03 2007 - 17:02:44 CEST