|
|
Posted by Kenneth Downs on 05/14/06 17:08
Dikkie Dik wrote:
>
> No, you don't. You know a FIELD value of your record, NOT its primary
> key. That you wish to combine them (that is always going to get you in
> trouble sooner or later) does not change anything. For clarity: A
> primary key is only a unique pointer to a record and nothing more.
> Especially, primary key values should never be related to the data in
> the record.
>
A natural primary key is one composed of one or more values that make up
part of the data being recorded. It sounds like our OP is describing a
natural key. Natural keys are a fundamental building block of relational
theory, going right back to Codd, allowing access to data only by the name
of the column values, w/o respect to any implementation-specific pointer
values or record numbers.
Your post describes what we usually call a surrogate key, to distinguish
from a natural primary key. The surrogate is generaly described as a
column that holds no business meaning, but which is unique. They are
usually implemented as sequential integers because those are handy, but
GUID's are sometimes used as well. Relational theorists often confuse
these with pointers and declare them to be evil, but they do not violate
any relational principles.
To make it more confusing, sometimes a natural key can be
computer-generated, such as a sales order #. That looks like a surrogate
to many people but it becomes meaningful outside of the system using it, so
it is really a natural key.
--
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec)ure(Dat)a(.com)
Navigation:
[Reply to this message]
|