Functions in the relational context

#1

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 (DOT) com> wrote:

Quote:

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.

#2

Tegiri Nenashi <TegiriNenashi (AT) gmail (DOT) com> wrote in news:ffb9d7ab-99d0-
44b3-91df-be581420f6c6 (AT) s12g2000...oglegroups.com:

Quote:

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 (DOT) 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 ?

#3

Tegiri Nenashi <TegiriNenashi (AT) gmail (DOT) com> wrote in news:ffb9d7ab-99d0-
44b3-91df-be581420f6c6 (AT) s12g2000...oglegroups.com:

Quote:

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 (DOT) 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 ?

#4

Tegiri Nenashi <TegiriNenashi (AT) gmail (DOT) com> wrote in news:ffb9d7ab-99d0-
44b3-91df-be581420f6c6 (AT) s12g2000...oglegroups.com:

Quote:

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 (DOT) 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 ?

#5

Tegiri Nenashi <TegiriNenashi (AT) gmail (DOT) com> wrote in news:ffb9d7ab-99d0-
44b3-91df-be581420f6c6 (AT) s12g2000...oglegroups.com:

Quote:

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 (DOT) 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 ?

#6

Tegiri Nenashi <TegiriNenashi (AT) gmail (DOT) com> wrote in news:ffb9d7ab-99d0-
44b3-91df-be581420f6c6 (AT) s12g2000...oglegroups.com:

Quote:

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 (DOT) 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 ?

#7

Tegiri Nenashi <TegiriNenashi (AT) gmail (DOT) com> wrote in news:ffb9d7ab-99d0-
44b3-91df-be581420f6c6 (AT) s12g2000...oglegroups.com:

Quote:

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 (DOT) 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 ?

#8

Tegiri Nenashi <TegiriNenashi (AT) gmail (DOT) com> wrote in news:ffb9d7ab-99d0-
44b3-91df-be581420f6c6 (AT) s12g2000...oglegroups.com:

Quote:

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 (DOT) 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 ?

#9

Tegiri Nenashi <TegiriNenashi (AT) gmail (DOT) com> wrote in news:ffb9d7ab-99d0-
44b3-91df-be581420f6c6 (AT) s12g2000...oglegroups.com:

Quote:

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 (DOT) 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 ?

#10

Tegiri Nenashi <TegiriNenashi (AT) gmail (DOT) com> wrote in news:ffb9d7ab-99d0-
44b3-91df-be581420f6c6 (AT) s12g2000...oglegroups.com:

Quote:

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 (DOT) 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 ?