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
surrogatekey based on a serial type, but in such cases that may not serve any purpose other than to have some arbitrary
primarykey.
>
> 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.
> 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.
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.