On Thu, Mar 1, 2018 at 2:07 PM, Rakesh Kumar <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! So using a primary key whose sole purpose is to be a primary key makes perfect sense to me.
