From: | Richard Broersma <richard(dot)broersma(at)gmail(dot)com> |
---|---|
To: | Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com> |
Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, John R Pierce <pierce(at)hogranch(dot)com>, PGSQL Mailing List <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Avoiding surrogate keys |
Date: | 2010-05-04 14:36:47 |
Message-ID: | AANLkTimDSvExnsKZ_yD2H_kYPdHWaKPMF9tdtkjE0ekH@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
2010/5/4 Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com>:
>
> Another thing, If your PK changes, it is no longer a PK, you can't rely on it.
Depending upon what you mean by changes this could be true or it could
be a matter of opinion. If your referring to a candidate key's value
changes, this key still provides a useful way to identify a tuple.
Also, just because a surrogate key is a useful way to identify a row,
by itself it does nothing to uniquely identify an entity that a row
represents. On some DBMS forums that I frequent, it is a daily
occurrence to see questions on how to eliminate duplicate rows. So,
for some people, there are times when even surrogate keys cannot be
relied upon as a PK.
--
Regards,
Richard Broersma Jr.
Visit the Los Angeles PostgreSQL Users Group (LAPUG)
http://pugs.postgresql.org/lapug
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-05-04 14:37:43 | Re: pg9 beta1, make check fails |
Previous Message | Sergey E. Koposov | 2010-05-04 14:36:23 | PG & random() strangeness |