From: | Rob Sargent <robjsargent(at)gmail(dot)com> |
---|---|
To: | Melvin Davidson <melvin6925(at)gmail(dot)com>, pgsql-general General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: PostgreSQL Developer Best Practices |
Date: | 2015-08-25 03:44:13 |
Message-ID: | 016FBA21-230D-4D54-A50F-177D6CDB6D89@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> On Aug 24, 2015, at 6:53 PM, Melvin Davidson <melvin6925(at)gmail(dot)com> wrote:
>
> You are right, he was probably talking about FK's. I was just so frustrated about people insisting that using "ID" as the primary key in every table is a "good" idea,
> I didn't bother to reply previously. I stand firm on my belief that the primary key should be something meaningful and NOT "id" just for the sake of having a unique numeric key.
>
What, pray tell, is the unique natural key of person in any meaningfully large domain such as state? Certainly not name + birthdate. Current address isn’t guaranteed. Social isn’t reliable and actually not truly unique.
Even given that there are models which are made of entities with legitimate attributes which per force define a unique instance, I see no benefit in avoiding the convenience of an arbitrary and simple value for the key. Is it the overhead of generating and storing one more value per tuple that you can’t abide?
From | Date | Subject | |
---|---|---|---|
Next Message | Gavin Flower | 2015-08-25 03:51:20 | Re: PostgreSQL Developer Best Practices |
Previous Message | David G. Johnston | 2015-08-25 02:45:52 | Re: PostgreSQL Developer Best Practices |