| 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: | Whole Thread | Raw Message | 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 |