On Thu, Mar 1, 2018 at 9:20 AM, Alban Hertroys <haramrae@gmail.com> wrote:
> Not to mention that not all types of tables necessarily have suitable candidates for a primary key.
They do if they are in 1NF. ( no dupes alllowed )
> An example of such tables is a monetary transaction table that contains records for deposits and withdrawals to
accounts.It will have lots of foreign key references to other tables, but rows containing the same values are probably
notduplicates.
That's a bad example. They would normally have a transaction id, or a
timestamp, or a sequence counter. PKs can expand all non-nullable
columns. You could try to come with a real example, but all the times
I've found these in one of my dessigns is because I didn't correctly
model the "real world".
> Adding a surrogate key to such a table just adds overhead, although that could be useful in case specific rows need
updatingor deleting without also modifying the other rows with that same data - normally, only insertions and
selectionshappen on such tables though, and updates or deletes are absolutely forbidden - corrections happen by
insertingrows with an opposite transaction.
And normally you would need to pinpoint an individual transaction for
selection, hard to do if you do not have a pk.
Francisco Olarte.
