On 03/01/2018 02:20 AM, Alban Hertroys wrote: [snip]
Not to mention that not all types of tables necessarily have suitable candidates for a primary key. You could add a surrogate key based on a serial type, but in such cases that may not serve any purpose other than to have some arbitrary primary key. 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. 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.
Wouldn't the natural pk of such a table be timestamp+seqno, just as the natural pk of a transaction_detail table be transaction_no+seqno?
-- Angular momentum makes the world go 'round.
