Re: Database Design: Maintain Audit Trail of Changes - Mailing list pgsql-general

From Bèrto ëd Sèra
Subject Re: Database Design: Maintain Audit Trail of Changes
Date
Msg-id CAKwGa_-Go28592hQ1SaZKPWkQeEX5gLS9_tgH4jvhk6BDk8s-w@mail.gmail.com
Whole thread Raw
In response to Re: Database Design: Maintain Audit Trail of Changes  (Fabrízio de Royes Mello <fabriziomello@gmail.com>)
List pgsql-general
Hi again,

> I understand it and for this reason I said to "use some strategy to purge
> old historical data *OR* make your audit tables partitioned"...

yes, prepare to scale up in any case, even if it seems to be a remote
chance ATM. If the "untouched" nature of this data is so critical, you
have no chances to tamper with it in the future, or it will lose its
value. On the contrary, being able to scale up to a very large amount
of historical data can be sold as a plus to the same audience/market,
as you clearly are planning to "think big".

If it cannot be partitioned because of budget concerns, a low cost
alternative is to print it out and have it authenticated by a notary
(since your historical records bear a prog number you clearly cannot
hide "sections" in the process). Pretty much what you do with
book-keeping.

Cheers
Bèrto

--
==============================
If Pac-Man had affected us as kids, we'd all be running around in a
darkened room munching pills and listening to repetitive music.


pgsql-general by date:

Previous
From: sk baji
Date:
Subject: Re: [ADMIN] Unable to reload postgresql.conf without restarting
Next
From: "Robert Klaus"
Date:
Subject: Re: Large number of rows in pg_type and slow gui (pgadmin) refresh