From: | Mark Stosberg <mark(at)summersault(dot)com> |
---|---|
To: | pgsql-sql(at)postgresql(dot)org |
Subject: | Peer-review requested of soft-delete scheme |
Date: | 2013-04-16 16:24:00 |
Message-ID: | kkjtv3$a75$1@ger.gmane.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Hello,
I'm working on designing a soft-delete scheme for our key entity-- there
are 17 other tables that reference our key table via RI. Let's call the
table "foo".
I understand there are a couple common design patterns for soft-deletes:
1. Use a trigger to move the rows to a "tombstone table".
2. Add an "deleted flag" to the table.
The "tombstone table" approach is out for us because all the RI.
The "deleted flag" approach would be a natural fit for us. There's
already a "state" column in the table, and there will only be a small
number rows in the "soft-deleted" state at a time, as we'll hard-delete
them after a few months. The table has only about about 10,000 rows in
it anyway.
My challenge is that I want to make very hard or impossible to access
the soft-deleted rows through SELECT statements. There are lots of
selects statements in the system.
My current idea is to rename the "foo" table to something that would
stand-out like "foo_with_deleted_rows". Then we would create a view
named "foo" that would select all the rows except the soft-deleted views.
I think that would make it unlikely for a developer or reviewer to mess
up SELECTs involving the statement. Inserts/Updates/Delete statements
against the table are view, and coud reference the underlying table
directly.
Is this sensible? Is there another approach to soft-deletes I should be
considering?
Thanks!
Mark
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Burnett | 2013-04-16 18:42:08 | building psycopg2 |
Previous Message | Tony Capobianco | 2013-04-13 22:05:32 | Re: pivot query with count |