Databases Reference
In-Depth Information
Objections to versioning every change to every column
because of storage considerations also overlook the fact that
on-line transaction tables take far more space in nearly every
organization than tables of persistent objects ever will, no matter
how frequently versions are created. In our experience, half a
petabyte of disk space to extend our transaction histories back
another few years is an easier sell to the CIO than a few dozen
gigabytes of disk space to support versioning the most important
persistent objects the enterprise engages with.
We also believe that objections to versioning every column of
every table of persistent objects overlook the orders of magni-
tude increases in available on-line storage volume, and the
orders of magnitude reduction in per unit cost for that storage.
In addition, these objections often overlook the fact that
versioning all changes to persistent object tables removes the
need to take periodic snapshots of those tables because any
snapshot of those tables, as of any point in past time, can be cre-
ated from those versions.
Another issue with mixing updates in place with versioning is
that updates in place create a potential inconsistency with other
versions of that same data. If there are 10 versions of an object,
let us suppose, and we do an update in place to one of those
versions, what should we do about the other versions? An update
in place is a non-temporal update, so perhaps we should repli-
cate that update onto all versions, earlier ones as well as later
ones. As an update in place column, our interpretation of its data
should be that it is always current. Whether or not we do repli-
cate the update onto past versions, we should probably replicate
it onto all future versions. And whatever replication strategy we
decide on, the performance cost of the replication process could
easily outweigh any savings in storage costs that might result
from avoiding one extra version.
Assertions
Creating a version of an episode of an object is, usually, to
assert that version. (Later on, we will discuss deferred assertions,
in which a row is asserted some time after it is created.) Just as a
version has an associated time period, an assertion does too.
The former time period is the effective time period of the version.
The latter time period is the assertion time period of the assertion.
Since both the version and its assertion are represented by the
same physical row, both time periods are associated with that row.
As we might imagine from this description, assertions are
handled with begin and end dates, just as versions are. The
