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

On Apr 30, 9:19 am, "Brian Selzer" <b..._at_selzer-software.com> wrote:
> "Cimode" <cim..._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.
I could say that on a logical perspective, I agree partly with that. But the chance for a system that do not separate logical and physical (namely a direct image system) layers to implement *systematically* such method is almost unexistant. That is why I brought up the idea of interpolation.

> 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.
You lost me on that. RM is 2VL not 3VL. I do not understand what you mean by nullable attributes. Are you speaking on a logical perspective? physical implementation? Received on Mon Apr 30 2007 - 10:47:27 CEST