Confessions of an IT Manager_Phil Factor

Section III: Software Projects: the Good, the Bad and the Pitiful 125
Phil Factor:
Excellent! We seem to have a broad agreement on the general
principles of the design. There's no sense in getting into to much detail
at this stage. (Thinks, if I run part of the way to Liverpool Street station,
I'll get that train)
Colin Compliance:
(clears throat) I'm a bit concerned about the auditability of this
NAD.
Phil Factor:
(Thinks: Two million years of human evolution just to get a Compliance
officer! Nature can be cruel. It doesn't seem right.)
Colin Compliance:
This design isn't going to get sign-off by the audit-compliance team.
Do you realise that we have to be able to reproduce invoices, advice
notes, returns and such paperwork exactly as first done? We have to
audit when an address changes. Any change of name has to be logged
with date, time, the database user and workstation. There have been
many frauds in the past that have involved changing a customer's
address, so the audit-compliance team will have a feeding-frenzy on the
design as it is so far.
Phil Factor:
(thinks: OK, next train in an hour's time. Might as well spread the
anguish) Good thinking, Colin. So that means we'll definitely need to
have all CRUD done via stored procedures, with a separate log for all
changes.
(Developers slump, despondent)
Colin Compliance:
(warming to the subject) Yes, the design will have to have a full
audit trail. We will need to make all tables time-based so that all
versions are kept, with an insertion-Date and termination-date, and the
SQL picks out the current one only due to its null termination-date.
We'll need a trigger to enforce the rule of having only one record with a
null termination-date where one would otherwise have a unique
constraint. We can then cross-check it with the separate audit log.