Re: A new proof of the superiority of set oriented approaches: numerical/time serie linear interpolation
From: Brian Selzer <brian_at_selzer-software.com>
Date: Thu, 03 May 2007 19:04:34 GMT
Message-ID: <6nq_h.6839$2v1.6676_at_newssvr14.news.prodigy.net>
>> "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.
Date: Thu, 03 May 2007 19:04:34 GMT
Message-ID: <6nq_h.6839$2v1.6676_at_newssvr14.news.prodigy.net>
"Cimode" <cimode_at_hotmail.com> wrote in message news:1178196183.332449.213970_at_c35g2000hsg.googlegroups.com...
> 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. >
What do you mean by correctly implemented?
>> 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.
>
I think I did in another post. I was trying to be concise.
>> 3. in a closed world, there is no such thing as "missing information."
> Finally one thing I can decipher and agree on. So?
>
So, if there is no such thing as "missing information," then how can there be systematic treatment of it? Received on Thu May 03 2007 - 21:04:34 CEST