Purely for discussion:
On Thu, 2002-10-17 at 22:23, Jules Alberts wrote:
>
> I have considered this. As a matter of fact, that is the way it is in
> our current db but I'm not really happy with it. Theoretically
CODE
> should never change and is therefore safe to use as primary key.
But
> having an "extra" serial primary key will make the db more
flexible
> regarding to unforeseen complications.
Could you not make NAME not unique? Then you could have a
new code for the same name, not affecting previous records. If a
code changes, then its a new code, or the old code with a new
name
>Yeah, this happens. Later people want to expire particular codes,
>or
>change their meaning, but not for the existing records that refer to
>them...
If all attributes are 'unique' I don't see how you could change a
codes 'meaning' without (effectively not mechanically) cascading
these changes to existing records
From my own experience, I would also say that there is value in
>being
>able to sequence the codes in a non-alphabetic order. I add
>another
"seq" column to such tables, to allow their ordering to be arbitrarily
adjusted as well.
Just wondering aloud
Cheers
Paul Butler
