Re: Enforce primary key on every table during dev? - Mailing list pgsql-general

From marcelo
Subject Re: Enforce primary key on every table during dev?
Date
Msg-id 6057ff27-b072-2827-1ca5-943ca423026f@gmail.com
Whole thread Raw
In response to Re: Enforce primary key on every table during dev?  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: Enforce primary key on every table during dev?  (geoff hoffman <geoff@rxmg.com>)
List pgsql-general


On 01/03/2018 17:32 , David G. Johnston wrote:
On Thu, Mar 1, 2018 at 1:24 PM, Ron Johnson <ron.l.johnson@cox.net> wrote:
Why have the overhead of a second unique index?  If it's "ease of joins", then I agree with Francisco Olarte and use the business logic keys in your joins even though it's a bit of extra work.

​The strongest case, for me, when a surrogate key is highly desirable is when there is no truly natural key and the best key for the model is potentially alterable.  Specific, the "name" of something.  If I add myself to a database and make name unique, so David Johnston, then someone else comes along with the same name and now I want to add the new person as, say David A. Johnston AND rename my existing record to David G. Johnston.  I keep the needed uniqueness ​and don't need to cobble together other data elements.  Or, if I were to use email address as the key the same physical entity can now change their address without me having to cascade update all FK instances too.  Avoiding the FK cascade when enforcing a non-ideal PK is a major good reason to assign a surrogate.

David J.

I suffered myself what David said as an example...



Avast logo

El software de antivirus Avast ha analizado este correo electrónico en busca de virus.
www.avast.com


pgsql-general by date:

Previous
From: Daevor The Devoted
Date:
Subject: Re: Enforce primary key on every table during dev?
Next
From: Ron Johnson
Date:
Subject: Re: Enforce primary key on every table during dev?