mchamati@gmail.com (Mauricio Chamati) writes:
> Postgree is the most amazing DB, even more it will be the only one that will
> remain free (the good ones) as MySQL has been taken. In order to move on with
> this project, as an Java Senior Architect, I am recomming to you guys to have
> an special "Section" for Audit tables. As we separate sequence in another seq,
> we should do the same for Audit tables. They have their own behavior, are less
> used, and so on. I got in the mailing list and am sending the email just to
> give this idea for you guys, keep in mind and implement as you want.
There is value to there being a tutorial (or such) available to explain
strategies for doing this.
I'm not so sure that this is something that properly belongs in the
Postgres reference documentation, as:
- There are various strategies in the handling of auditing data, and
no forcibly normative/universal solutions;
- This isn't an explanation of how to use Postgres (ergo part of the
"user guide" aspect of the documentation);
- This isn't an aspect of the standard behaviour of Postgres (ergo
part of the "reference manual" aspect of the documentation).
It might be sort of neat to have another "Part" to the documentation
that consists of stuff like:
- Design patterns
- Design antipatterns (to avoid!)
- Cookbook
- Implementation strategies
(and there is overlap between those 4 things, to be sure!)
But that's not a portion of the Official Documentation that presently
exists, so I'm not sure it properly fits.
People have written articles on this sort of thing in the past,
including:
- Elein Mustain, with material at varlena.com
- Postgres Online Journal <http://www.postgresonline.com/>
- Articles blogged at Planet PostgreSQL
--
select 'cbbrowne' || '@' || 'gmail.com';
http://www3.sympatico.ca/cbbrowne/postgresql.html
"There are no threads in a.b.p.erotica, so there's no gain in using a
threaded news reader." -- (Unknown source)
