Re: Surrogate Keys: an Implementation Issue

<snip>

> >>
> >>His problem goes a lot deeper than his assumption about examples. The
> >>real root of the problem is his belief that he has a valid point to make.
> >
> > It is a valid point.
>
> Only if you make the fundamental mistake of pretending a non-key is a key.

No. There is a fundamental difference between a unique proposition (tuple) as taken simply from the mathematical definition of a relation as a minimum criterion for identity of a proposition, and the definition of a functional dependency that determines a primary key or candidate key. While most make the assumption that the two types of identity are equivalent, the assumption is fundamentally flawed, IMO. Often it might be the case that they are indented to be the same, but it is not guaranteed to be universally so.

So there are several issues that could be at play here. There is the gap between internal and external predicate over domains, or alternatively the gap between the universive of discourse and a strict symbolic interpretation. Moreover, the difference between a unique sentence taking all attribute values into consideration and the approach of analyzing functional dependences, which isolates the set of attributes into determinant sets and the set of attributes being determined is a subtle distinction, but one that has major implications nonetheless. Both of these can lead to confusion over whether we are more interested in the fact as a proposition being unique and discernable from different facts, or whether we are interested more in properties about some symbolic representation of a conceptual entity being more important, the representation revolving around a key construct.

To some degree from a strictly literal standpoint, key dependencies are a hack job that are disabused. There is no proscription against having two determinants of different value functionally resolve to the same attribute/property values across a proposition, nor is there a proscription that in the cases where they do resolve to the same determined values, they are the same thing in the conceptual space with different identifying names. Whether this results in different literal identities or an equivalency must often be judged on a case by case basis.

Equivalency plays a big part in this, and of course this is different than comparing and determining equality of identity by comparing all properties of an element. If you need some concrete abstract fat to chew, take equivalence of boolean expressions as a starting point and ask yourself whether two truth tables that have the same values but are use different logical expressions are the same or equivalent.

Alphabetic case is another case in point. By strict standards, only one symbolic representation (including case) should be used as a key, but most implementations certainly don't accomodate this easily and usually for those that are truly purists, a CONSTRAINT xxxx CHECK (variable = UPPER(variable)) is necessary in order to meet an ideal. These are just off the top of my head examples, but there seems to me to be plenty of evidence that writing off these issues to poor design and bad taste instead of recognizing the theoritical validity of such conditions might be a bit premature.

• Dan