Re: View challenge
From: paul c <toledobythesea_at_oohay.ac>
Date: Sat, 12 Aug 2006 15:42:41 GMT
Message-ID: <RFmDg.372730$Mn5.262260_at_pd7tw3no>
>> J M Davitt wrote:
>>
>>> frebe73_at_gmail.com wrote:
>>>
>>>>> ...
>>> You're asking for more rows - not just different
>>> representations of existing data in existing rows.
>>>
>>> The best row-maker we've got is the cartesian
>>> product - but that won't "fill-in" any gaps: the
>>> only values you see "output" are representations
>>> of the "input."
>>>
>>> If you change the requirements so that that the
>>> interval [valid_from, valid_to] is constant - or,
>>> at least, limited to some reasonable value - and
>>> can presume that intervals for individuals don't
>>> cover each other, you can cobble together a bit
>>> of cheese that UNIONs a bunch of SELECT-crafted
>>> rows. Like the way Celko would do it.
>>
>>
>> Or he could use a closure to calculate the necessary series of
>> integers or dates.
>
> Exactly right. But can it be done in MySQL's SQL?
Date: Sat, 12 Aug 2006 15:42:41 GMT
Message-ID: <RFmDg.372730$Mn5.262260_at_pd7tw3no>
J M Davitt wrote:
> Bob Badour wrote:
>> J M Davitt wrote:
>>
>>> frebe73_at_gmail.com wrote:
>>>
>>>>> ...
>>> You're asking for more rows - not just different
>>> representations of existing data in existing rows.
>>>
>>> The best row-maker we've got is the cartesian
>>> product - but that won't "fill-in" any gaps: the
>>> only values you see "output" are representations
>>> of the "input."
>>>
>>> If you change the requirements so that that the
>>> interval [valid_from, valid_to] is constant - or,
>>> at least, limited to some reasonable value - and
>>> can presume that intervals for individuals don't
>>> cover each other, you can cobble together a bit
>>> of cheese that UNIONs a bunch of SELECT-crafted
>>> rows. Like the way Celko would do it.
>>
>>
>> Or he could use a closure to calculate the necessary series of
>> integers or dates.
>
> Exactly right. But can it be done in MySQL's SQL?
Or, is this a good reason for an implementation that supported <NOT> ala TTM, eg., take the product of the complement of two empty relations and theta join with the desired range? Optimizer/compiler would have to be smart enough to not materialize the complete complements, I guess.
p Received on Sat Aug 12 2006 - 17:42:41 CEST