From: | "paul butler" <paul(at)entropia(dot)co(dot)uk> |
---|---|
To: | pgsql-novice(at)postgresql(dot)org |
Subject: | Re: char() or varchar() for frequently used column |
Date: | 2002-10-17 12:28:55 |
Message-ID: | T5dfef1d908ac1785b30c3@pcow057o.blueyonder.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
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
From | Date | Subject | |
---|---|---|---|
Next Message | paul butler | 2002-10-17 12:42:52 | where clauses with and |
Previous Message | Andrew McMillan | 2002-10-17 11:03:31 | Re: Trying to transform results of dow |