In most tables it is enough to have a stored procedure that performs Update Else Insert logic for data managment. However, in some cases we do not want to destroy the old data with an update statement. Instead we want to maintain history up to a certain number of versions. For example a bank may wish to keep records of a customer's address changes. Another classic example mentioned by most data warehouse writers is a name change. A woman gets married and changes her name, but we wish to keep a record of both the current name and the historical name.
We can track this information by having a main ID (an integer) in the table and then another ID for tracking changes (a decimal). In my example we have the integer field, CompanyID and then the dwCompanyID, a decimal. We version from n.10 to n.90. So nine versions of the CompanyID are allowed.
Our example is of a business that needs to track CreditStatus history for the last nine changes.The last version number must always be the most current.
If the CompanyID already has nine records in it the oldest record (CompanyID.10) is dropped, and then all the remaining records (.20 through .90) are decremented by one. Thus we can insert our record and it becomes the ninth version (CompanyID.90).
We also need to check if this is a valid version change. We need to check if the value in the CreditStatus field is actually different from the value held by the latest version. Otherwise we would see a history of a version change even if nothing had changed.
Thus suppose we enter a CreditStatus of 1 for Company 1. First parameter is CompanyID, second is CreditStatus. sp_slowChangeDim 1,1 The table will now look like this.
CompanyID dwCompanyID CreditStatus Date 1 1.10 1 Apr 25 2000 12:21PM
If we entered sp_slowChangeDim 1,1 another time there would be no changes. However, if we change the CreditStatus to 2 using "sp_slowChangeDim 1, 2" we would get a valid new version created.
CompanyID dwCompanyID CreditStatus Date 1 1.10 1 Apr 25 2000 12:21PM 1 1.20 2 Apr 25 2000 12:23PM