Re: Database Design: Maintain Audit Trail of Changes

Поиск
Список
Период
Сортировка
От Bèrto ëd Sèra
Тема Re: Database Design: Maintain Audit Trail of Changes
Дата
Msg-id CAKwGa_-Go28592hQ1SaZKPWkQeEX5gLS9_tgH4jvhk6BDk8s-w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Database Design: Maintain Audit Trail of Changes  (Fabrízio de Royes Mello <fabriziomello@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: sk baji
Дата:
Сообщение: Re: [ADMIN] Unable to reload postgresql.conf without restarting
Следующее
От: "Robert Klaus"
Дата:
Сообщение: Re: Large number of rows in pg_type and slow gui (pgadmin) refresh