Databases Reference
In-Depth Information
version. If we could depend on that being true, which means if
we could depend on there never being a requirement to support
multiple episodes of the same object, then the effective end date
would be redundant.
One could make the argument that all versions within one
episode have versions that [meet] and so, within each episode,
the end date could be inferred. Although that is true, we would still
need an episode end date to mark the end of the episode.
Furthermore, the end dates on each version significantly improve
performance because both dates are searched on the same row,
reducing the need, otherwise, for expensive subselects on every read.
Also, we are not interested in implementing just the minimal
temporal requirements a specific business use may require,
especially when it would be difficult and expensive to add
additional functionality, such as support for multiple episodes
(i.e. for temporal gaps between some adjacent versions of the
same object), to a database already built and populated, and to
a set of maintenance transactions and queries already written
and in use. All asserted version tables are ready to support gaps
between versions. On the other hand, as long as temporal trans-
actions issued to the AVF do not specify an effective begin date,
that capability of Asserted Versioning will remain unused and
the mechanics of its use will remain invisible.
As for the second objection, an assertion end date would be
redundant with the following asserted version's assertion begin
date only if every assertion of a version followed the previous
one without a gap of even a single clock tick in assertion time.
But once again, we are not interested in implementing just the
minimal temporal requirements a specific business use may
require. All asserted version tables are ready to support deferred
assertions, and deferred assertions may involve a gap in asser-
tion time. On the other hand, as long as temporal transactions
issued to the AVF do not specify an assertion begin date, that
capability of Asserted Versioning will remain unused and the
mechanics of its use will remain invisible.
In addition, as we will see in following chapters, single vers-
ions can be replaced by multiple versions as new assertions are
made, and vice versa. In that case, the logic for inferring asser-
tion begin dates from the assertion end dates of other versions
could become quite complex. This complexity could affect the
performance, not only of maintenance transactions, but also of
queries. The reason is that, if we followed this suggestion, it
would be impossible to determine, from just the data on any
one row, whether or not that row has an Allen relationship with
the assertion time specified on a query. To determine that, we
