Re: candidate keys in abstract parent relations

In this case, I guess I'm being finicky because if I use a generated
key column, it's *not* going to be a truly surrogate key: a surrogate
key implies that there is a candidate key for which the new key is
acting as a surrogate, and as defined, my album table lacks any
candidate keys. It's entirely possible that duplicate rows will be
added to the table without some kind of nonce or generated identifier
being added to its definition, so the entire justification for adding a
generated column is to guarantee uniqueness over the relation.
According to my (definitely shaky) grasp of the relational model, this
is a bad idea, and I'm afraid doing things this way exposes a weakness
in the underlying data model, even if I can't identify it.

Also, on a more abstract level, I'm trying to derive a method for
dealing with similar problems in the future. It seems to me like this
is a common problem when trying to model real-world domains, and there
have to be methods for coping with scenarios in which the identity of a
row is tied to the set of child rows dependent upon it in an
association.

.

Relevant Pages

  • Re: A real world example
    ... the surrogate is only needed to ... there are things that will identify me over my lifetime (in this ... Either way the relational model must not hide it. ... x int primary key references P, ...
    (comp.databases.theory)
  • Re: How should I generate a primary key?
    ... Relational Model to Capture More Meaning", ... "The need for unique and permanent identifiers for database entities ... Database users may cause the system to generate or delete a surrogate, but they have no control over its value, nor is its value ever displayed to them. ... Modelling in Data Base Management Systems, G.M. Nijssen, ed., ...
    (comp.databases)