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.
