Re: What databases have taught me

Aloha Kakuikanu wrote:

Bob Badour wrote:

Consider:

Ra = Rb AND x = 1 AND y = 1

Where Ra and Rb are two relvars. Is that still a join? To what do x and
y refer?


There is ambiguity caused by multiple equality signs. Did you mean

(Ra = Rb) AND x = 1 AND y = 1

or

Ra := (Rb AND x = 1 AND y = 1)

The first interpretation is absurd since there is no equality operator
in relational algebra.

It exists in mine. It exists in the Date/Darwen one too. I disagree that it is ambiguous because obviously equality has a higher precedence than AND. Otherwise, R AND x = 1 AND y = 1 would end up as (R AND x) = (1 AND y) = 1, which I don't think you intended in any of your previous examples.


In the second case there is no longer equality,
but assignment := (and I still keep the redundant brackets for
clarity).

I meant the first case, of course.


Consider:

R AND x = 1 AND y = 1

where R has no x attribute. Will that cause a compile-time error? Why or
why not?

No. The cartesian product of

R AND y = 1

with

x = 1

is the EXTEND operator.

While that sort of thing might make sense for the internal algebra used by the dbms, I prefer something that yells loudly when I type anything that is almost certainly an error -- especially when the error would likely cause the query to run for orders of magnitude longer duration than expected.


I realize that this kind of thinking would steer quite away from exact
Tutorial D semantics. BTW, only now I noticed that Tutorial D is
bastardised version of D&D "A" algebra. Of course, it may be argued
that the connection Tutorial D <--> "A" is better designed than SQL
<--> RA, but this parallel is kind of ironic.

I suggest there is a difference between the best formalism for a machine and the best formalism for a human, which is why compilers often start by converting programs into some sort of DAG as a first step.
.

Loading