views:

75

answers:

4

Hallo all,

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 realeas a record for a version. I alsow have to be able to rollback to the old ones. The reason is that I want exports for diffrent versions of the data.

+3  A: 

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. I.E., If auditing is your purpose you could add database triggers and store the old and new values in a seperate [Audit] table.

Kane
Well said. Always define the problem before proposing a solution.
Leslie
Yeah... but we've all done it, guess that's why coding is so much fun
Kane
I added more information to the question.
nickik
+2  A: 

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.

Larry Lustig
That was my first take to but lets say someone changes there Name (in the example above. Then you would make a new version in the main entity but the change in the Name table would destroy the old version. You could of course model that in you application but for every table more it would need more application code. There needs to be a more general system.
nickik
In that case, the entity being versioned is the "user registration record". That record would have PK, OriginalPK, and VersionID fields. When the name changed you would create a new record with new PK, OriginalPK set to the OriginalPK on "parent" record, and VersionID incremented by 1. You would not copy or even update the FKs back to the People table on any transactions (because you want to preserve the original "version" of the user registration that the transaction was associated with, but your UI could show that there is updated information for that user.
Larry Lustig
Thats was what im was looking for thanks.
nickik
+1  A: 

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.

Roadie57