Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]

In article <1120237546.473797.242280_at_f14g2000cwb.googlegroups.com>, marshall.spight_at_gmail.com says...
> > > >>>Would these issue be solved with opaque keys?
> > > >>
> > > >>Yes, that is at the core of my suggestion: a decent theoretical
> > > >>foundation for opaque keys, abstract identifiers, or whatever you want
> > > >>to call them.
> >
> > A surrogate key (that you don't show anyone) fulfills the same purpose.
>
> I'm not sure I know what you mean, but I don't think that's right.
> If the key has a concrete value, then it might collide with a
> key with the same value when you don't want it to. If the keys
> are opaque then they won't collide when you move from table to
> table. Hmm. It's kind of like identity. :-(

I am not familiar with opaque keys, but I can't imagine how anything can *not* have a concrete value. If you are going to use it in the RM, you must be able to compare it with other things of the same type. Otherwise, how can you ascertain that it is unique? Not to mention perform joins. However, that does not mean it must support other operators than =. In particular, it does not necessarily need an operator to convert it to a string for display on screen.

I also don't understand the requirement that they not collide with keys in other tables. Facts involving the same key may be encoded in several relvars, and when you join them or take their union, you *want* them to "collide". If you want all keys of all "entities" to be "globally" unique, you need to define them on the same domain, and use the same key generator---but what is the use of that? And moving from database to database---the only way to ensure that keys don't collide is to generate new ones for the ones you move, unless you have a common key generator. After all, the opaque keys must be represented by bit patterns, like everything else.

You can simulate all this with surrogate keys, but it complicates the model (you now have a "special" kind of domain, with special restrictions and rules), and it limits your options when designing the database. And it is logically equivalent to row ids, with the conceptual overhead, complexity and problems related to that. It might be the best solution for a given problem/application anyway, but I think that should be decided at the application level, not carved in stone at the model level.

-- 
Jon