----- Original Message -----
From: "Ron Johnson" <ron.l.johnson@xxxxxxx>
To: <pgsql-general@xxxxxxxxxxxxxx>
Sent: Wednesday, February 14, 2007 3:46 PM
Subject: Re: [GENERAL] backup database by cloning itself
It seems to me that if you really want a historical record of what
certain tables looked like in the past, it would be smarter and more
accurate to create triggers, for each possible operation, that store the
relevant details in an audit table including especially who made the
edits and when. This strikes me as being much less work than developing
code that processes so many backups.
I dunno about that. We use triggers to populate log tables that get
extracted, truncated then loaded into a reporting db every night.
Because of the night time batch cycle, there is no quiescent time to
do this, so we have 2 log tables, and the triggers alternate which
log table to insert into, depending on whether the day number is
even or odd.
That's in addition to the trigger logic to insert into history tables.
It's a royal pain.
Sounds painful, but not as painful as trying to do the same thing with a
suite of backups and client code to read the backups. Or maybe the latter
task is easier than it looks at first glance.
Doesn't the amount of pain depend on the amount of traffic your servers see,
the capability of the hardware you can devote to the task, what you're doing
with the history tables, &c.? When I've worked on this kind of problem,
everything was in a single DB. The traffic, though, was low enough that for
daily reports a simple view of the log selecting only the previous day's
data, was sufficient, but only occasionally used. The principal reason for
the log was to support accountability, to know who made changes, and when,
and who knew what when. Historical reconstructions were required, e.g.,
only when something went awry and there was a need to know if a good
decision was made based on bad data or a bad decision was made based on good
data, or, e.g., during an audit of the business processes and decision
support systems.
Cheers,
Ted
