Re: PostgreSQL Developer Best Practices

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

In response to

Responses

Browse pgsql-general by date

  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