The foundation for your business
Fork me on GitHub
Re: [ledgersmb-devel] Primary key for tables "eca_to_contact", "entity_to_contact", "entity_bank_account"
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ledgersmb-devel] Primary key for tables "eca_to_contact", "entity_to_contact", "entity_bank_account"

Your proposed change looks good to me.

Sent from my Samsung Galaxy Note 4 on the Telstra Mobile network

-------- Original message --------
From: Erik Huelsmann <..hidden..>
Date: 23/08/2017 05:22 (GMT+08:00)
To: ..hidden..
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.




http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
devel mailing list