On Thu, Mar 1, 2018 at 9:20 AM, Alban Hertroys <haram...@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 not duplicates. 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 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. And normally you would need to pinpoint an individual transaction for selection, hard to do if you do not have a pk. Francisco Olarte.
