Re: A new proof of the superiority of set oriented approaches: numerical/time serie linear interpolation
Date: Mon, 30 Apr 2007 04:19:04 -0400
Message-ID: <ZDhZh.4346$uJ6.1594_at_newssvr17.news.prodigy.net>
"Cimode" <cimode_at_hotmail.com> wrote in message
news:1177913751.812247.69630_at_n76g2000hsh.googlegroups.com...
> On 29 avr, 23:01, "Brian Selzer" <b..._at_selzer-software.com> wrote:
>> "Cimode" <cim..._at_hotmail.com> wrote in message
>>
>> news:1177873628.360842.277700_at_u30g2000hsc.googlegroups.com...
>> [snip]
>>
>> > I can not say I disagree with what you are saying but I still think
>> > you are missing the point of the example.
>>
>> > As a practionner who used intensively both procedural and set based
>> > methods, on may manage to get response time to be faster using cursors
>> > (that still need s to be established) but that does not mean that
>> > performance as a whole is improved.
>>
>> > Self joins poor implementations is a known direct image systems
>> > limitation. That is the issue I was trying to underline here.
>> > Discussing tuning on a specific SQL DBMS implementation is not the
>> > point of the thread nor the point of the NG. THe main point here is
>> > to see if linear interpolation could be a way of handling
>> > systematically missing numeric/datetime data...
>>
>> I think that self-joins would be problematic regardless of the
>> implementation. They are necessary only when dependencies exist between
>> tuples within the same relation. It's like using a single relation for
>> graphs instead of one relation for verticies and a separate relation for
>> edges. It can be done, but should it?
> I do not understand where do you see a self join? >
>> On to your main point: Are you suggesting that the schema definition for
>> a
>> temporal relation include some form of "active" default definition,
>> wherein
>> a scalar expression would be stored in lieu of a value? Or maybe not
>> stored, but evaluated whenever a missing value is accessed? Sounds like
>> an
>> interesting idea. I think the semantics would require some form of
>> second-order logic, however.
> I just think that handling missing data through NULLS is just the > worst way of doing it. So I think interpolation may probably be > closer to what Codd had in mind by formulating the prerequisite for a > dbms to be able to have a *systematic way missing data*.(or at least > numeric/datetime data)
NULLs can be eliminated by splitting a relation horizontally. The only thing lost in the process is the sense of applicability, but that can be overcome by creating a third relation with an applicability attribute and either one or two foreign key constraints, depending on whether or not the attribute always applies. With nullable attributes there's no need for a third relation, and sometimes not even a second. If an attribute always applies (a functional dependency exists), but some of the values may be absent, then a nullable attribute would be in order. If an attribute sometimes applies, but when it does, a value is always present, then a separate relation with a foreign key constraint would suffice. If an attribute sometimes applies, but even when it does, a value may be absent, then a separate relation with a foreign key constraint along with a nullable attribute would be needed. In this way it can be determined from the schema definition whether an attribute applies always or sometimes, and when it does apply, whether a value can be absent.
>> [snip]
>
>
Received on Mon Apr 30 2007 - 10:19:04 CEST