Intelligent ways to maintain versioned copies of tables in a relational database (programming considerations?)

Question

My second consideration was to simply make a copy of the table data associated with the active document or folder of documents that the baseline was applied to, and store that for safe keeping. The code complexity savings would be enormous, the schema would be kept simpler though there is some impact in terms of storage usage (though I do not believe it will be that big)

Answer 1

This is something I'm faced with as well on a current project. Some good answers here.

I'm personally using option #1, adding a version column to the pkey of each "versioned" table. FKeys use the version column as well. My main consideration was ease of querying, with a consequence of high storage requirements. I have the leeway to strictly limit the number of versions kept around, which mitigates that issue.

Answer 2

I really think you are looking for a temporal database. Our own implementation added a pair of audit log identifiers to a table, the "create ID" and "delete ID" (and every transaction that modified the database was summarized in an "audit log" and given a unique sequential identifier). For each transaction that added a record to the table, the audit log identifier was used as the create ID and the delete ID was zero. When a record changed, the new version had the new create ID and the same identifier was used as the delete ID for the old version.

It was quite easy to create a view of a table where the delete ID was zero, creating a virtual table of just current data. You could also find the content of the tables just before or just after a specific transaction was processed, get a list of the transactions that modified a specific row of a table, etc.

There are time, space, and complexity penalties for all this. But for us, dealing with large sums of money, it was worth it.