Versioning in relational database

Question

I have a problem to introduce a good versioning in my database design.

Let's make a easy example. A little rental service.

You have a table Person (P_ID, Name) , table Computer (C_ID, Type) and a table Rent (R_ID, P_ID, C_ID, FromData, ToData) .

I want to be able to change say the user name, create a new version and still have the old stuff at hand if I need it.

My goal is to have some kind of system on my websites witch makes it easy to make a versioning of some records in a table.

More Information:

I have business logic that demands that I can release a record for a version. I also have to be able to rollback to the old ones. The reason is that I want exports for diffrente versions of the data.

Answer 1

Before jumping into the solution it might be a good idea to ask what behaviour are you wanting to achieve? Do you need versioning for some auditing purpose, do you need versioning so that users can rollback changes, do you need versioning for some business rule, or is there another reason?

Once you know this the answer should pretty much jump out at you. IE, If auditing is your purpose you could add database triggers and store the old and new values in a seperate [Audit] table.

Answer 2

You have made a statement (that you want versioning), but not asked a question (exactly what your problem is). Without a question, it's hard to provide an answer.

In general, you could provide versioning by:

1. Identifying what entity needs to be versioned. In this case it sounds like you may want to be versioning a "deal" or "rental agreement".

2. Add a PK column, version number column, and "originalID" column to the table at the top of the model for that entity.

3. To do versioning, copy top level record to a new PK, placing the original PK in the "originalID" column and incrementing the version number column. Copy the related tables, changing the FK in those tables to match the PK of the new record. Then allow the user to modify the records pertaining to the new-PK version of the record.

Answer 3

You could use triggers:

http://weblogs.asp.net/jgalloway/archive/2008/01/27/adding-simple-trigger-based-auditing-to-your-sql-server-database.aspx

Answer 4

You could create an Archive table that you update via stored procedure or trigger that is populated with a copy of all the fields in a data row in the primary table after every update or insert. The archive table would have its own PK and time stamps for when changes were made.