The model I described is indeed tailored more for tracking changes and
archiving historical records because those were the requirements of the
project I was implementing ;-) I just had to figure out the most optimal way
of addressing these requirements using MySQL 4.1.
MERGE tables are an excellent way of segmenting the history views to span
different storage containers and (I haven't tried this yet) packing the
tables that form the view might further speed things up while saving storage
I was wondering though whether an incremental SQL storage engine existed in
open source, MySQL or otherwise. One capable of inserting a row in a table
based on some other row by storing only the fields that differ between the
two, and ideally performing diffs between large text fields. Any clues ?
----- Original Message -----
To: <dali@stripped>; <mysql@stripped>
Sent: Friday, April 15, 2005 5:23 PM
Subject: Re: Temporal databases & MySQL
What you describe makes sense and would certainly work, I don't know
that I would call it a temporal solution. The ENUM (I, U, D) seams a bit
redundant with time. This model resembles a traditional application log
or trace file, which is highly desirable for a records keeping system,
like for a phone company, or auto dealership. But if your looking for a
dynamic time based model to support systems that might track plants and
animals that have lived or live on earth that show extinction,
reintroduction and evolution...your stuck with start times and end times
marking valid entries and a large "WHERE clause" using "BETEEN st_date
AND en_date". If you stick with the T_HIST model you may want to check
out the MERGE tables, they can help segment your older histories while
still giving you a VIEW like access, assuming you can't go to the MySql
From: news [mailto:news@stripped] On Behalf Of Daniel BODEA
Sent: Saturday, April 09, 2005 8:46 PM
Subject: Re: Temporal databases & MySQL
I was thinking about the following model for the application I'm working
Any given table T holds the conventional data associated with instant
no temporal data at all. There are tables T_HIST for every table T with
identical structure plus one date column which is set to NOW on every
(these tables are only inserted into) and another ENUM column holding an
identifier for the operation (I, U or D). An index would be created over
both (date, operation).
An INSERT in T is duplicated in T_HIST. An UPDATE is first performed in
and the resulting row is INSERTed in T_HIST. A DELETE first copies the
column into T_HIST and the row is deleted from T.
As long as all T tables have PKs that are guaranteed not to be recycled,
suppose the benefits would be the following:
T tables can be kept compact and fast for all mundane operations.
Since the history can only grow and is logically separated, it can use
separate storage strategies better fit for much larger amounts of data
compared to tables T.
Temporal data remains a minimal addition while allowing for all (?)
queries to be performed. I initially thought there would be
where queries would have to perform a join to the corresponding T tables
then the ENUM column should fully replace the join.
Index usage for temporal queries in the MySQL context should be optimal
using the date column as the main index on a table that is naturally
guaranteed to have this column ordered at all times.
Views and triggers would be simulated by the application which should
too incumbent considering that the application needs to provide some
means of changing the "querying instant" anyway.
I'm in no way favoring any temporal model if it's not for its ability to
perform best on a given SQL engine (MySQL in this case). Not being that
familiar with the inner workings of MySQL though, I can only submit the
module above to the attention of MySQL specialists who may have the time
post back their thoughts.
"Daniel BODEA" <dali@stripped> wrote in message
> Hi Shawn,
> I really meant temporal and not temporary. Temporal as in TSQL2.
> that on the one hand accumulate all changes to data over time along
> accurate time information and on the other hand provide varying
> transparency in querying this data based on the theory of instants and
> aggregated intervals of time.
> Most of the resources available online are largely academic though.
> Google :
> Troels' links has a good temporal databases section :
> The TAU Project that has some experimental code for several engines of
> MySQL :
> I need to use this fully in a project that uses MySQL 4.1.latest and
> way that's independent of the structure of tables comprising the
> I'm not looking for TSQL2 implementations for MySQL or other types of
> esoteric implementations at the SQL level. I was just interested in
> from people who have used MySQL to implement this model in a
> environment and what they could say about both the storage of temporal
> and the optimization of queries on past instants and intervals.
> There are several partially incompatible ways of doing this in a
> relational context but as always, only one is most fit for a given SQL
> engine and I'm currently asking about it for MySQL.
> I can't possibly be the first one to push this thing onto MySQL based
> production-quality requirements.
> > I am not familiar with the use of the adjective "temporal" with the
> > "database". To me "temporal" means "of or having to do with time or
> > measurement". Could you have meant "temporary" which means to me
> > "non-permanent or transitory in nature."?
> > Even if you had meant "temporary", I rarely hear it used as a
> > design term except when used with the word "table" as in "temporary
> > table". (http://dev.mysql.com/doc/mysql/en/create-table.html)
> > However, if the TAU project is doing research on databases that are
> > displaced or movable through time, this may be something I want to
> > involved with. What is their URL?
> > Shawn Green
> > Database Administrator
> > Unimin Corporation - Spruce Pine
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe:
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql