Databases Reference
In-Depth Information
Views are particularly useful for supporting an environment
in which new queries are frequently written, and in which those
queries are often run once or twice, and then discarded. These
“what-if” queries are usually written by business researchers
and analysts, sometimes with and sometimes without the assis-
tance of query tools. We will call them ad hoc queries.
But developer-written queries, most of which exist within
application programs, usually do not make use of views.
They are production queries, the ones which are run over and
over again to produce standard reports and data extracts, usually
on a standard schedule.
One reason that developers usually write queries directly
against physical tables is that simplification is not an important
benefit for them. (If it is, perhaps they should consider another
line of work!) Another is that the queries which developers write
are usually written, tested and put into production where they
will be run over and over again. Developers generally don't sit
around writing throw-away queries all day long.
But the main reason that developers usually write queries
directly against physical tables is that views are restrictive. For
the most part, criteria in views are hardcoded, and do not make
use of variables. For example, CURRENT_DATE can be used in
most views, but a user-defined date or timestamp cannot.
Production queries, which are run day after day, for weeks,
months or years, often need to include user-defined variables,
and especially dates and timestamps. In contexts like application
programs, the benefits of views are negligible, while the flexibil-
ity of writing queries directly against physical tables is essential.
With Asserted Versioning's bi-temporal tables, the flexibility
of writing queries directly against those tables is even more
valuable. As we will see in Chapters 12-14, the full range of
all possible bi-temporal data is covered by nine categories of
that data, those categories being the three-by-three combina-
tion of data which is in the past, present or future of either
assertion time or effective time. Because the AVF guarantees
that all data in asserted version tables is semantically valid
(as far as bi-temporality is concerned), queries against that data
need nothing more than one or two additional predicates,
over and above the predicates needed for the query if it were
against a conventional table. These predicates specify a date
or a time period (specified as a pair of dates), and one of the
Allen relationships or other nodes in our Allen relationship
taxonomy, and the query will return only those rows whose
assertion and/or effective time periods satisfy those predicates.
The ability to write queries that retrieve data from any or all
