If your really that worried about this you will just have to have an
effective date and an expiration date on the codes. Leave the expiration
date either null or a VERY VERY large value.
On Thursday 17 October 2002 07:21 am, you wrote:
> On 17 Oct 2002 at 13:28, paul butler wrote:
> > 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
> Both CODE and NAME are unique. And they will _never_ change. Until they
> do :-). These are mostly tables which are not our own, stuff like
> country codes, medical diagnosises etc. They comply to ISO standards.
> Someone may decide to change them. Of course we could tackle this by
> using an UPDATE CASCADE, but beside that I want a truly unique and
> unchangeable column in the table. Hence the ID field, which is
> redundant as long as nothing unchangeable changes, merely a safeguard.
> > >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
> > ---------------------------(end of broadcast)---------------------------
> > TIP 3: if posting/reading through Usenet, please send an appropriate
> > subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> > message can get through to the mailing list cleanly
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
In response to
pgsql-novice by date
|Next:||From: Josh Berkus||Date: 2002-10-17 23:13:42|
|Subject: Re: Random tuple?|
|Previous:||From: Josh Berkus||Date: 2002-10-17 19:37:59|
|Subject: Re: How to extract hour and minutes from a timestamp|