On Mon, 2006-11-27 at 15:47 -0700, Scott Ribe wrote:
> >>> insert a new address, and update the users table to the new address_id
> >>
> >> Which changes the user's "primary key". My point was that having the address
> >> id be part of the primary key is wrong.
> >
> > As I said, you don't *have* to do it that way. I was just giving an
> > example. You could just as easily grab the address id, insert that into
> > an archive table with a date stamp and then just update the address
> > itself. Thus *not* changing the "Primary Key".
>
> Thus making it more difficult to deal with historical data, and also
> reducing the "address id" in the "user" row to nothing more than an
> additional auto-generated number referencing address data that might as well
> just be put into the user row, because that would be no less normalized
> anyway than this single address row whose contents keep changing to
> represent different addresses over time.
O.k., do you make it a point of over analyzing everything? I gave a very
simple example of how to not use an artificial key and why it could be
bad. I wasn't meant to be a golden parachute.
Of course there are problems with the example. It was a 10 second
example with zero business or data requirements qualified around it.
Please... find something more productive to do.
Sincerely,
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
