On 03/01/2018 11:47 AM, Daevor The Devoted wrote:
On Thu, Mar 1, 2018 at 2:07 PM, Rakesh Kumar <rakeshkumar...@aol.com
<mailto:rakeshkumar...@aol.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.