Databases Reference
In-Depth Information
Jan 10
Jan
2010
Jan
2011
Jan
2012
Jan
2013
Jan
2014
INSERT INTO Policy (BK, client, type, copay, crt_dt, updt_dt)
VALUES ('P861', 'C882', 'HMO', '$15', CURRENT_DATE, NULL)
BK
client
type
copay
crt-dt
updt-dt
P861
C882
HMO
$15
Jan10
{null}
INSERT INTO Policy (BK, ver_dt, client, type, copay)
VALUES ('P861', CURRENT_DATE, 'C882', 'HMO', '$15')
BK
ver-dt
client
type
copay
P861
Jan10
C882
HMO
$15
Figure 4.1 Conventional and Basic Version Tables: An Insert Transaction.
a basic version table of those same policies. Above each table is
the SQL statement that inserted or most recently altered the data
in that table.
In each table, primary key columns are indicated by under-
lining their column headings. In each table, the italicized col-
umnisaforeignkeytoatablewhichw lmakeitsfirst
appearance in Chapter 11. Type and copay are the two business
data columns in both tables. Create date and update date in
the non-temporal table are, respectively, the date the row
was inserted into the table, and the date the row was last
updated.
In all sample tables, dates are shown in the format “mmmyy”.
Thus, “Jan10” is short for January 1
st
, 2010, which is the start of
the January 2010 clock tick. Since the clock used in most of these
examples ticks once a month, the notation is unambiguous. The
reason for the “mmmyy” representation is that it takes up mini-
mal horizontal space on the page, which is important for the
sample transactions,
rows and tables used in illustrations
throughout the topic.
In the version table, there is no update date because rows are
not physically updated. Instead, each logical update is carried
out by copying the most current version, applying the update
to the copy and inserting the result as the new most current ver-
sion. As for a physical create date, that is the same thing as the
version date in basic versioning.
