Re: Unique Keys

Kenneth Downs wrote:
> I would suggest it is more useful to define the equality operator as
such:
>
> where x = (a,b)
> and y = (c,d)
>
> x = y iff (a <= c <= b) OR (a <= d <= b)
>
> It is the equality operator definition that makes it a declarative
unique
> constraint exactly the same as any other, and also makes possible
simple
> foreign keys. Now we have:
>
> CREATE TABLE reservations (
> hotel_room char(4),
> span DATEINTERVAL )
> PRIMARY KEY (hotel_room,span)

Yes, but only by subverting the traditional meaning of "equals"! So what do you do now if you want to know if the 2 DATEINTERVALs really are the same?

> And the super-nifty:
>
> CREATE TABLE Something_Else (
> ....
> hotel_room char(4),
> span DATEINTERVAL )
> FOREIGN KEY (hotel_room,span)
> REFERENCES reservations (hotel_room,span)

... which means what, given your redefinition of "="? That each Something_Else row must overlap (but not necessarily match or even be contained within) a Reservations row? I can't imagine a use for that, really. Received on Fri Nov 26 2004 - 04:08:41 CST