From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
---|---|
To: | William Temperley <willtemperley(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Design decision advice |
Date: | 2008-08-14 01:55:33 |
Message-ID: | 48A39095.9030701@postnewspapers.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
William Temperley wrote:
> Dear all
>
> I'd really appreciate a little advice here - I'm designing a PG
> database to manage a scientific dataset.
> I've these fairly clear requirements:
>
> 1. Multiple users of varying skill will input data.
> 2. Newly inserted data will be audited and marked good / bad
> 3. We must have a dataset that is frozen or "known good" to feed into
> various models.
>
> This, as far as I can see, leaves me with three options:
> A. Two databases, one for transaction processing and one for
> modelling. At arbitrary intervals (days/weeks/months) all "good" data
> will be moved to the modelling database.
> B. One database, where all records will either be marked "in" or
> "out". The application layer has to exclude all data that is out.
You could also exclude "out" data at the database level with appropriate
use of (possibly updatable) views.
If you put your raw tables in one schema and put your valid-data-only
query views in another schema, you can set your schema search path so
applications cannot see the raw tables containing not-yet-validated data.
You also have the option of using materialized views, where a trigger
maintains the "good" tables by pushing data over from the raw tables
when it's approved.
That gives you something between your options "A" and "B" to consider,
at least.
--
Craig Ringer
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2008-08-14 01:58:11 | Re: PostgreSQL and SVN - help me... |
Previous Message | Alvaro Herrera | 2008-08-14 01:37:18 | Re: automatic REINDEX-ing |