Search Postgresql Archives

Re: Normal vs Surrogate Primary Keys...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Oct 01, 2006 at 07:48:14PM -0700, rlee0001 wrote:
> <snip> For example, if I key "employee" by Last Name, First Name, Date
> of Hire and Department, I would need to store copies of all this data
> in any entity that relates to an employee (e.g. payroll, benefits and
> so on). In addition, if any of these fields change in value, that
> update would need to cascade to any related entities, which might be
> perceived as a performance issue if there are many related records.

Err, those fields don't make a natural key since they have no guarentee
of uniqueness. You've simply decided that the chance of collision is
low enough that you don't care, but for me that's not really good
enough for use as a key.

Secondly, three of the four fields you suggest are subject to change,
so that indeed makes them a bad choice. My definition of "key" includes
"unchanged for the lifetime of the tuple".

In that situation your idea may work well, but that's just a surrogate
key in disguise...

Have a nice day,
-- 
Martijn van Oosterhout   <kleptog@xxxxxxxxx>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

Attachment: signature.asc
Description: Digital signature


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux