Databases Reference
In-Depth Information
The Scope and Limits of Best Practice
Versioning
Versioning maintains a history of the changes that have hap-
pened to policies and other persistent objects. It also permits us
to anticipate changes, by means of proactively creating new
versions, creating them in advance of when they will go into
effect. All four of the basic types of versioning which we have
reviewed in this chapter provide this functionality.
Basic versioning is hardly ever used, however, because its
deletions are physical deletions. But when a business user says
that a policy should be deleted, she is (or should be) making a
business statement. She is saying that as of a given point in time,
the policy is no longer in effect. In a conventional table, our only
option for carrying out this business directive is to physically
delete the row representing that policy. But in a version table,
whose primary purpose is to retain a history of what has hap-
pened to the things we are interested in, we can carry out that
business directive by logically deleting the then-current version
of the policy.
Logical delete versioning, however, is not very elegant. And the
cost of that lack of elegance is extra work for the query author.
Logical delete versioning adds a delete flag to the schema for
basic versioning. But this turns its version date into a homonym.
If the flag is set to “N”, the version date is the date on which that
version became effective. But if the flag is set to “Y”, that date is
the date on which that policy ceased to be effective. So users
must understand the dual meaning of the version date, and must
include a flag on all
their queries to explicitly draw that
distinction.
Temporal gap versioning is an improvement on logical delete
versioning in two ways. First of all, it eliminates the ambiguity in
the version date. With temporal gap versioning, that date is
always the date on which that version went into effect. When
the business says to delete a policy as of a certain date, the
action taken is to set the version end date on the currently effec-
tive version for that policy to that date. No history is lost. The
version date is always the date the version became effective.
There is no flag that must be included on all the queries against
that table.
Secondly, temporal gap versioning can record a situation in
which instead of beginning exactly when a prior version ended,
a version of a policy begins some time after the prior version
of that policy ended. Expressed in business terms, this is the
