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
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.
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