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: Mon, 30 Apr 2007 04:19:04 -0400
Message-ID: <ZDhZh.4346$uJ6.1594@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 - 03:19:04 CDT