From: | Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Enforce primary key on every table during dev? |
Date: | 2018-03-01 18:18:42 |
Message-ID: | 5a1870db-7018-fe15-ac60-ffe37abb7077@cox.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 03/01/2018 11:47 AM, Daevor The Devoted wrote:
>
> On Thu, Mar 1, 2018 at 2:07 PM, Rakesh Kumar <rakeshkumar464(at)aol(dot)com
> <mailto:rakeshkumar464(at)aol(dot)com>> wrote:
>
>
> >Adding a surrogate key to such a table just adds overhead, although
> that could be useful
> >in case specific rows need updating or deleting without also
> modifying the other rows with
> >that same data - normally, only insertions and selections happen on
> such tables though,
> >and updates or deletes are absolutely forbidden - corrections happen
> by inserting rows with
> >an opposite transaction.
>
> I routinely add surrogate keys like serial col to a table already
> having a nice candidate keys
> to make it easy to join tables. SQL starts looking ungainly when you
> have a 3 col primary
> key and need to join it with child tables.
>
>
> I was always of the opinion that a mandatory surrogate key (as you
> describe) is good practice.
> Sure there may be a unique key according to business logic (which may be
> consist of those "ungainly" multiple columns), but guess what, business
> logic changes, and then you're screwed!
And so you drop the existing index and build a new one. I've done it
before, and I'll do it again.
> So using a primary key whose sole purpose is to be a primary key makes
> perfect sense to me.
I can't stand synthetic keys. By their very nature, they're so
purposelessly arbitrary, and allow you to insert garbage into the table.
--
Angular momentum makes the world go 'round.
From | Date | Subject | |
---|---|---|---|
Next Message | Francisco Olarte | 2018-03-01 18:20:04 | Re: Enforce primary key on every table during dev? |
Previous Message | Francisco Olarte | 2018-03-01 18:08:20 | Re: How to avoid trailing zero (after decimal point) for numeric type column |