Databases Reference
In-Depth Information
IT professionals. They are the reason we turn to such version
tables in the first place.
But version tables are often required to do one more thing,
which is to manage temporal gaps between versions of objects.
In a non-temporal table, these gaps correspond to the period
of time between when a row representing an object was deleted,
and when another row representing that same object was later
inserted.
When only one version date is used, each version for an
object other than the latest version is current from its version
date up to the date of the next later version; and the latest ver-
sion for an object is current from its version date until it is logi-
cally deleted or until a new current version for the same object is
added to the table. But by inferring the end dates for versions in
this way, it becomes impossible to record two consecutive vers-
ions for the same object which do not [meet]. It becomes impos-
sible to record a temporal gap between versions.
To handle temporal gaps, IT professionals often use two ver-
sion dates, a begin and an end date. Of course, if business
requirements guarantee that every version of an object will begin
precisely when the previous version ends, then only a single ver-
sion date is needed. But this guarantee can seldom be made; and
even if it can be made, it is not a guarantee we should rely on.
The reason is that it is equivalent to guaranteeing that the busi-
ness will never want to use the same identifier for an object
which was once represented in the database, then later on was
not, and which after some amount of time had elapsed, was
represented again. It is equivalent to the guarantee that the busi-
ness will never want to identify an object as the reappearance of
an object the business has encountered before.
Let's look a little more closely at this important point. As diffi-
cult as it often is, given the ubiquity of unreliable data, to support
the concept of same object, there is often much to be gained. Con-
sider customers, for example. If someone was a customer of ours,
and then for some reason was deleted from our Customer table,
will we assign that person a new customer number, a new identi-
fier, when she decides to become a customer once again? If we do
so, we lose valuable information about her, namely the informa-
tion we have about her past behavior as a customer. If instead
we reassign her the same customer number she had before, then
all of that historical information can be brought to bear on the
challenge of anticipating what she is likely to be interested in
purchasing in the near future. This is the motivation for moving
beyond logical delete versioning to the next versioning best prac-
tice—temporal gap versioning.
