primary key and existing unique fields

[Sally Sally]

Hi all,
I am wandering about the pros and cons of creating a separate serial field
for a primary key when I already have a single unique field. This existing
unique field will have to be a character of fixed length (VARCHAR(12))
because although it's a numeric value there will be leading zeroes. There
are a couple more tables with similar unique fields and one of them would
need to reference the others. Does anybody see any good reason for adding a
separate autoincrement primary key field for each table? or either way is
not a big deal.
Sally

__________________________________________________ _______________
Don’t just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/o...ave/direct/01/
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[Joshua D. Drake]

Sally Sally wrote:

Hi all,
I am wandering about the pros and cons of creating a separate serial
field for a primary key when I already have a single unique field. This
existing unique field will have to be a character of fixed length
(VARCHAR(12)) because although it's a numeric value there will be
leading zeroes. There are a couple more tables with similar unique
fields and one of them would need to reference the others. Does anybody
see any good reason for adding a separate autoincrement primary key
field for each table? or either way is not a big deal.
Your primary key should not be directly related to the data being
stored. Outside of the fact that it is the primary reference or the row.

Sincerely,

Joshua D. Drake
Sally

__________________________________________________ _______________
Don’t just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/o...ave/direct/01/


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

--
Command Prompt, Inc., home of PostgreSQL Replication, and plPHP.
Postgresql support, programming shared hosting and dedicated hosting.
[phone] - [e-mail] - http://www.commandprompt.com
Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Dawid Kuroczko]

On Tue, 26 Oct 2004 16:24:44 +0000, Sally Sally <de*****@hotmail.com> wrote:

Hi all,
I am wandering about the pros and cons of creating a separate serial field
for a primary key when I already have a single unique field. This existing
unique field will have to be a character of fixed length (VARCHAR(12))
because although it's a numeric value there will be leading zeroes. There
are a couple more tables with similar unique fields and one of them would
need to reference the others. Does anybody see any good reason for adding a
separate autoincrement primary key field for each table? or either way is
not a big deal.

I see three possible advantages:

1. having varchar(12) in every referencing table, takes more storage
space, which may mean something if you have tons of gigabytes of rows.
;)
2. if any of your varchar(12) row's data is likely to change in
future, you'll make update of one table, not an update which will
CASCADE over many tables.
3. If you'll need things like "last 50 keys", you can SELECT * FROM
foo ORDER BY yourserialkey DESC LIMIT 50;

And a disadvantage:
if you'll need to access the data by your varchar(12) key, you'll need
to perform JOIN on two tables. If you used varchar(12) as your key,
you don't. :)

Regards,
Dawid

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Richard Huxton]

Sally Sally wrote:

This
existing unique field will have to be a character of fixed length
(VARCHAR(12)) because although it's a numeric value there will be
leading zeroes.

Plenty of people are contributing their tuppence-worth regarding the
choice of surrogate vs natural primary key.

Can I just point out that your existing unique field is EITHER a numeric
value OR it has a fixed number of characters - numbers don't have
leading zeros.

If what you have is a number, then perhaps consider int8/numeric types
and format appropriately when you display the values.

--
Richard Huxton
Archonet Ltd

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

[Bruno Wolff III]

On Wed, Oct 27, 2004 at 00:10:27 +0200,
Dawid Kuroczko <qn****@gmail.com> wrote:

3. If you'll need things like "last 50 keys", you can SELECT * FROM
foo ORDER BY yourserialkey DESC LIMIT 50;

You really shouldn't be doing that if you are using sequences to generate
the key. Sequences are just guarenteed to return unique values, not to
return them in order. Because groups of sequences can be allocated to
a backend at once depending on a setting settable by a client, you can
get assignments out of order. Also for overlapping transactions what
the application means by the last 50 entries may not match what you
get when you get the 50 highest serial values.

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly