From: | Igor Neyman <ineyman(at)perceptron(dot)com> |
---|---|
To: | Melvin Davidson <melvin6925(at)gmail(dot)com>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
Cc: | Jerry Sievers <gsievers19(at)comcast(dot)net>, John R Pierce <pierce(at)hogranch(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: PostgreSQL Developer Best Practices |
Date: | 2015-08-26 13:45:53 |
Message-ID: | A76B25F2823E954C9E45E32FA49D70ECCD5127D0@mail.corp.perceptron.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
From: pgsql-general-owner(at)postgresql(dot)org [mailto:pgsql-general-owner(at)postgresql(dot)org] On Behalf Of Melvin Davidson
Sent: Tuesday, August 25, 2015 8:18 PM
To: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
Cc: Jerry Sievers <gsievers19(at)comcast(dot)net>; John R Pierce <pierce(at)hogranch(dot)com>; pgsql-general(at)postgresql(dot)org
Subject: Re: [GENERAL] PostgreSQL Developer Best Practices
….
Before ANYONE continues to insist that a serial id column is good, consider the case where the number of tuples will exceed a bigint.
Don't say it cannot happen, because it can.
……………………
Melvin Davidson
Now, it’s easy to overcome this limitation.
You just make concatenated PK (id1, id2) with both columns of BIGINT type.
In general, I see the main advantage of artificial PK in NO NEED to change multiple child tables, when NATURAL key changes in the parent table. And I never saw a system where NATURAL key wouldn’t need to be changed eventually.
So, my conclusion: use artificial PK (for db convenience) and unique NATURAL key (for GUI representation).
Regards,
Igor Neyman
From | Date | Subject | |
---|---|---|---|
Next Message | Karsten Hilbert | 2015-08-26 13:47:45 | Re: PostgreSQL Developer Best Practices |
Previous Message | Adrian Klaver | 2015-08-26 13:14:00 | Re: backup and archive postgresql data older than 6 months |