Your proposed change looks good to me.
Sent from my Samsung Galaxy Note 4 on the Telstra Mobile network
-------- Original message --------
From: Erik Huelsmann <ehuels(a)gmail.com>
Date: 23/08/2017 05:22 (GMT+08:00)
Subject: [ledgersmb-devel] Primary key for tables
"eca_to_contact", "entity_to_contact", "entity_bank_account"
While working on some of the 1.5.10-planned fixes, I'm running into the problem that
the three tables in the subject have primary keys which contain non-numeric data. More
specifically, in case of the bank account data, the pkey contains the bic and account
number and in case of the contact data, the pkey contains a user-description of the
contact item in the pkey (together with a class).
Knowing about the privacy protection regulations in the EU, I think that having the
bic+iban in the pkey of a table which is to describe that data isn't practical (both
because it already exposes the primary data through the pkey and because it exposes
heavily sensitive data to all tables which want to enable looking this data up.
For the contact table, things are a bit different: I'm thinking that having an
(editable) user description in the pkey simply isn't a great idea.
Proposed way forward: All three tables get a serial "id" column, which is made
the PKEY, where we can opt to make a UNIQUE index out of the columns which currently
determine the PKEY.
-- Hosted accounting and ERP.Robust and Flexible. No vendor lock-in.