Databases Reference
In-Depth Information
could involve adjusting the configuration of the database and
server, or making changes to the applications and the SQL that
maintain and query the database. As authors of this topic, we
can't participate in the specific modify and monitor iterative pro-
cesses being carried on by any of our readers and their IT
organizations. But we can describe factors that are likely to apply
to any Asserted Versioning implementation.
These factors include the number of users, the complexity of
the application and the SQL, the volatility of the data, and the
DBMS and server platform. The major DBMSs may optimize
varying configurations differently, and may have extensions that
can be used to simplify and improve a “plain vanilla” implemen-
tation of Asserted Versioning.
In this chapter, we will take a broad brush approach and, in
general, discuss optimization techniques that apply to the
temporalization of any relational database, regardless of what
industry its owning organization is part of, and regardless of
what types of applications it supports. Each reader will need to
review these recommendations and determine if and how they
apply to specific databases and applications that she may be
responsible for.
To repeat once more as we read the following sections,
although we use the term “date” in this topic to describe the
delimiters of assertion and effective time periods, those delimiters
can actually be of any time duration, such as a day, minute,
second or microsecond. We use a month as the clock tick granu-
larity in many of our examples. But in most cases, a finer level of
granularity will be chosen, such as a timestamp representing the
smallest clock tick supported by the DBMS.
Performance Tuning Bi-Temporal
Tables Using Indexes
Many indexes are designed using something similar to a
B-tree (balanced tree) structure, in which each node points to
its next-level child nodes, and the leaf nodes contain pointers
to the desired data. These indexes are used by working down
from the top of the hierarchy until the leaf node containing
the desired pointer is reached. Each pointer is a specific index
value paired with the physical address, page or row id of the
row that matches that value. From that point, the DBMS can
do a direct read and retrieve the I/O page that contains the
desired data.
