Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search archives
  Advanced Search

Re: IS it a good practice to use SERIAL as Primary Key?


  • From: Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net>
  • To: pgsql-general(at)postgresql(dot)org
  • Subject: Re: IS it a good practice to use SERIAL as Primary Key?
  • Date: Thu, 23 Nov 2006 10:23:55 -0600
  • Message-id: <4565CB1B.7060008@cox.net> <text/plain>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/22/06 20:23, carter ck wrote:
> Hi all,
> 
> I am wonderring if it is a good practice to use SERIAL index as primary
> key, as it is only available up to 9999999?
> 
> Currently i am dealing with storing LDAP users into Postgres and i am
> looking for a better way to make use of the DN as primary key instead of
> SERIAL index.
> 
> Any advice or suggestion is appreciated.

I'm one of those who thinks that a (possibly multisegment) natural
key *does* exist, and that if you think it doesn't, your design is
wrong.

For those times when and that when numeric sequences *are* needed
(employee_id and account_number for example) they should include a
check digit, to ensure that you don't mis-type a number and charge
the wrong account.

[I'm old enough to have worked in a Service Bureau where lots women
keypunched form data into Mohawk key-to-tape machines, and check
digits, which are also in credit cards and SSNs, are a perfect way
to protect against typos.]

- --
Ron Johnson, Jr.
Jefferson LA  USA

Is "common sense" really valid?
For example, it is "common sense" to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that "common sense" is obviously wrong.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFZcsbS9HxQb37XmcRAmtYAJ44k15B2bX8GQ6MegaEFGxeWm9q6gCgoVAT
w+exLaR8symCHDzKwSgp5q0=
=uIq6
-----END PGP SIGNATURE-----



Home | Main Index | Thread Index

Privacy Policy | About PostgreSQL
Copyright © 1996 – 2012 PostgreSQL Global Development Group