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.