Re: Database Design: Maintain Audit Trail of Changes

From: Bèrto ëd Sèra <berto(dot)d(dot)sera(at)gmail(dot)com>
To: fabriziomello(at)gmail(dot)com
Cc: Rich Shepard <rshepard(at)appl-ecosys(dot)com>, PostgreSQL General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Database Design: Maintain Audit Trail of Changes
Date: 2013-01-03 17:49:43
Message-ID: CAKwGa_-Go28592hQ1SaZKPWkQeEX5gLS9_tgH4jvhk6BDk8s-w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Scott Ribe 2013-01-03 18:02:34 Re: Unable to reload postgresql.conf without restarting
Previous Message Robert Klaus 2013-01-03 17:45:31 Re: Large number of rows in pg_type and slow gui (pgadmin) refresh