On May 29, 1:13 pm, Symeon <syme... (AT) gmail (DOT) com> wrote:
I replied to this, but my reply seem to not have posted, so I will
reply again.

Timestamping and audit logging is a subset of Temporal Data. The stuff
you are doing is based only on the capabilities of U2 (et al) to
handle just that subset. To handle temporal data in the real meaning
you need a temporal database. Wikipedia has a reasonable introduction
http://en.wikipedia.org/wiki/Temporal_database that explains the
issues better than I apparently have.

Would you guys just give up trying to argue with Antony? Fun, but ultimately
like Chinese food, you realize that there ain't no there there (or is that
Oakland?) But this was fun. Temporal database is a term I'd never heard of
outside Startrek Voyager, so, thanks.

OK: I read with my usual bs filters on, (or should I say marginal disdain)
the Wikipedia entry, which, as A. correctly states, is an excellent example.
What's the meat of the issue?

1- That a subsequent transaction which *logically* may override a previous
one does not *physically* do so. So for our lucky bugger who got the Feb
raise retroactively, there'd be two pay transactions, one reflecting
"reality" (in which camp I stand firmly) and one "virtual" transaction which
pretends that said employee was actually paid 2500 on Feb 1. Maybe there'd
be three or four, but it's a finite number.

In the wiki example, where Mr Doe, who seems to have some unique problems
with his life, lies about his address, it's similar: an entry (correct)
which gives his address and another entry (the lie) with his fictitious
address.

2- Firstly, other than the convoluted reasons that make this "necessary", I
see *nothing* about this that could not easily be "solved" (an overblown
term in the circumstances) by a half-decent programmer. It's the
programming, ....uh... silly. It's easily done

3-Secondly, the apparent importance of this is no doubt arguable, but let's
be charitable and say it needs to be done. If the frequency of such
transactions is low, I guess this was easily solved in the
pre-temporal-database era by that catchall field "comments". But then you'd
have to have a human being read and interpret the results, which I sort of
agree is beyond database mathematica. So maybe it's necessary.

4-Obviously, the reporting engine has a harder task when asked to maintain
continuity. Again, using MV (or maybe just "human understandable")
terminology, I'd assume that the real, overridden and virtual reality
transactions could easily be flagged as such, thereby making an ad-hoc query
like "LIST EMPLOYEE WITH NAME PURPORTING.TO.BE "John Doe" REAL.ADDRESSES
CLAIMED.ADDRESSES FROM.DATE TO.DATE WITH DATE > "1/1/00" AND < "1/1/07"
almost feasible at the MV Retrieval language level.

That said, Tony, can I join your staff as a Temporal DataBase proto-Expert?
I'm afraid I'm not too good at marketing myself.

Chandru Murthi

"Anthony Lauder" <anthony.lauder (AT) gmail (DOT) com> wrote