>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.
