On 01/03/2018 16:00 , Ron Johnson wrote:
On 03/01/2018 12:32 PM, Daevor The Devoted wrote:
On Thu, Mar 1, 2018 at 8:18 PM, Ron Johnson <ron.l.john...@cox.net
<mailto:ron.l.john...@cox.net>> wrote:
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.
Could you perhaps elaborate on how a surrogate key allows one to
insert garbage into the table? I'm afraid I don't quite get what
you're saying.
If your only unique index is a synthetic key, then you can insert the
same "business data" multiple times with different synthetic keys.
--
Angular momentum makes the world go 'round.
IMHO, business logic can and must preclude "garbage insertion". Except
you are inserting data directly to database using SQL, any n-tier
architecture will be checking data validity.
---
El software de antivirus Avast ha analizado este correo electrónico en busca de
virus.
https://www.avast.com/antivirus
