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/onm00200636ave/direct/01/

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

[Joshua D. Drake]

Re: primary key and existing unique fields

Sally Sally wrote:[color=blue]
> 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.[/color]

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


[color=blue]
> 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[/color]


--
Command Prompt, Inc., home of PostgreSQL Replication, and plPHP.
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandpromp t.com - 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]

Re: primary key and existing unique fields

On Tue, 26 Oct 2004 16:24:44 +0000, Sally Sally <dedeb17@hotmai l.com> wrote:[color=blue]
> 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.[/color]

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]

Re: primary key and existing unique fields

Sally Sally wrote:[color=blue]
> 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.[/color]

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 majordomo@postg resql.org so that your
message can get through to the mailing list cleanly

[Bruno Wolff III]

Re: primary key and existing unique fields

On Wed, Oct 27, 2004 at 00:10:27 +0200,
Dawid Kuroczko <qnex42@gmail.c om> wrote:[color=blue]
> 3. If you'll need things like "last 50 keys", you can SELECT * FROM
> foo ORDER BY yourserialkey DESC LIMIT 50;[/color]

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 majordomo@postg resql.org so that your
message can get through to the mailing list cleanly