Re: Functions in the relational context
Date: Thu, 6 Mar 2008 21:45:56 +0100 (CET)
Message-ID: <Xns9A59A0780B9D1vdghher_at_194.177.96.26>
Tegiri Nenashi <TegiriNenashi_at_gmail.com> wrote in news:ffb9d7ab-99d0- 44b3-91df-be581420f6c6_at_s12g2000prg.googlegroups.com:
> Many people from both side of the fence suggested that functional
> programming is a promising idea that can embrace both paradigms. Here
> is why I don't think so. Consider the earlier cute exercise:
>
> On Mar 6, 10:55 am, Tegiri Nenashi <TegiriNena..._at_gmail.com> wrote:
>> What function the following query >> >> SELECT x FROM sine WHEN y=0.5 >> >> represent?
>
> We have a relation Sine(x,y), which in SQL looks like this
>
> table Sine (
> x number;
> y number;
> )
>
> One can go ahead and start inserting the values into it, until he
> realizes that this relation is infinite, so it is better be something
> else than a table. To simplify the discussion, however, I'll continue
> to pretend that it is a table (that is relation with finite number of
> tuples).
>
> Now, consider the query
>
> SELECT y FROM sine WHEN x=pi/4
>
> Without any index on the Sine table, the execution has to scan all the
> values and filter only those that satisfy the predicate. We'd better
> have some index to make a quick execution:
>
> create unique index sin on Sine(x);
>
> With this index in place the execution is just a unique index scan,
> then the retrieval of the matching tuple from the table. Likewise, if
> we have
>
> SELECT x FROM sine WHEN y=1/2
>
> then we'd better have an index
>
> create index arcsin on Sine(y);
>
> Unlike the previous case it is no longer a unique.
>
> Now does it coincidental, that I named the indexes "sin" and "arcsin",
> implying that there is perhaps some similarity to the functions sin(),
> and arcsin()? (The latter being multivalued function, of course). Not
> at all, the only difference is in implementation:
>
> * The index "sin" calculates the value sin(pi/4) by performing a
> lookup in some structure.
>
> * The function "sin" calculates the value sin(pi/4) by performing
> arithmetic operations.
>
> This idea IMO is a vehicle to extending relations to the infinite
> case. We can't scan infinite relations in principle, but can join them
> by the means of the indexes -- that is the functions.
>
>
I do not see how your exercise, whilst no doubt cute, discredits the idea that FP can be fruitfully applied to the data management field. Care to provide the missing link/s in your logical chain, like, 'in the RA we can do such and so, but in FP we cannot, therefore, FP is really no good'. Besides, on its face, the exercise is not really relevant to the RA data management. Are you talking about something like constraint databases where you operate with formulas rather than data ? Received on Thu Mar 06 2008 - 21:45:56 CET