|
|
Posted by Ed Prochak on 03/07/06 19:25
Doug wrote:
> >(but the ID field is still a poor crutch for a possibly weak design.)
>
> hmmmm. i'd prefer to think of it as the table stores ALL hits to the
> table, but this particular data consumer only wants to see ONE.
It isn't clear that this was ONE of several data consumers.. Even so
the ID pseudokey might not be the best choice.
> The
> way I think about it, your natural key would be the composite of all
> fields in the table; perhaps "natural", but certainly awkword.
>
> I like figital's solution.
It is not clear from the previous posts that the natural key would
require ALL the columns of that table. If the table is really storing
events, then the key might be as simple as a timestamp, perhaps with an
event type. It doesn't have to be ALL of the columns.
My point is too many people immediately jump to ID fields as the PK.
Many times before they even sit down to think about what entity the
table represents. If you never look for the natural key, you are sure
not to find it.
HTH
ed
Navigation:
[Reply to this message]
|