temporary databases

After spending some time at

http://dimlab.usc.edu/cs599-2000/

I don't understand the elementary: what is the subject of temporal databases? Suppose we have a history table. Are there any queries that can't be expressed in standard SQL?

Isn't interval just defined by a couple of trivial predicates t1<time and time<t2? What is the purpose of introducing interval datatype if it's not closed under union operator?

According to Date/McGoveran a database is a repository of valid facts. Those facts are valid in *absolute* sence. We either say "Smith is teaching CS215 class" or say it more presizely "Smith was teaching CS215 class startind at 9am 10-Dec-1990 and ended at 9am 10-Mar-1991". If the second date is open-ended, it's just incomplete information. Wouldn't putting a null better than inventing some "transaction time"?

Snodgrass p299: "We learn on Jan 26 that Exa bought the flat not on Jan 10 as initially thought, not on Jan3 as later corrected, but on Jan 5" -- only abstraction-challenged person can consider paragraph like that seriously. Just fix the data, not the model!

Given a table of intervals answering a query what intervals cover that point is not trivial. Is this the only issue we could reduce temporal databases subject to?

Clifford Heath <cjh_nospam_at_managesoft.com> wrote in message news:<3CED8250.D010727D_at_managesoft.com>...
> This sort of database feature is useful of course, but (1) isn't necessarily
> the most efficient way to handle historical queries (need to follow the log
> chain back possibly many steps), (2) doesn't make it easy to identify
> which history should be kept past log backup interval(s) and (3) prevents
> revision of incorrect histories.
>
> There's still a need in many cases to model history explicitly.
Received on Fri May 24 2002 - 21:54:16 CDT