Databases Reference
In-Depth Information
contains no temporal data about persistent objects at all.
1
And
from now on, we will use the term “conventional database” to
refer to databases that may or may not contain temporal data
about persistent objects (and that usually do), but that do not
contain explicitly bi-temporal tables and instead incorporate
temporal data by using variations on one or more of the ad
hoc methods we have described.
Response Times in Bi-Temporal and
in Conventional Databases
At the level of individual tables, a table lacking temporal
data will clearly have less data than an otherwise identical table
that also contains temporal data. But even if a table has more
data than another table, it may perform nearly as well as that
other table because response times are usually not linear to the
amount of data in the target table.
Response times will be approximately linear to the amount of
data in the table in the case of full table scans, but will almost never
be linear for direct access reads. A direct (random) read to a table
with five million rows will perform almost as well as a direct read
to a table with only one million rows, provided that the table is
indexed properly and that the number of non-leaf index levels is
the same. And, inmost cases, they will be the same, or very close to it.
In addition, when adding in the overhead of triggers of an expo-
nentially growing number of dependents, and of the often ineffi-
cient SQL used to access and maintain data in conventional
databases, it is likely that using the AVF to manage temporal data
in an Asserted Versioning database will prove to be a more efficient
method of managing temporal data than directly invoking DBMS
methods to manage temporal data in a conventional database.
The Optimization Drill: Modify, Monitor,
Repeat
Performance optimization, also known as “performance tun-
ing”, is usually an iterative approach to making and then moni-
toring modifications to an application and its database. It
1
The point of adding “about persistent objects”, of course, is to distinguish between
objects and events, as we did in our taxonomy in Chapter 2. So a “non-temporal
database”, in this new sense, may contain event tables, i.e. tables of transactions. And
it may also contain fact-dimension data marts. What it may not contain is data about
any historical (or future) states of persistent objects.
