On Mon, Apr 16, 2012 at 5:04 PM, Simon Slavin <slav...@bigfraud.org> wrote: > On 16 Apr 2012, at 10:31pm, Peter Aronson <pbaron...@att.net> wrote: >> You might want to look at the book Temporal Data and the Relational Model by >> Date, Darwin and Lorentzos, which goes into the subject in fairly great >> detail. >> There are subtleties. > > Doctor Darwen teaches this as a course. You might like to read the free > detailed course notes here: > > <http://www.dcs.warwick.ac.uk/~hugh/TTM/TemporalData.Warwick.pdf>
Thanks for the reference. > I urge again the different approach I mentioned earlier. Forget keeping the > data, and instead keep the commands used to change the data. That way, > instead of keeping the /results/ of your SQL commands, you're keeping the > commands yourself, which is rawer (more raw ?) data, and therefore more > faithful to what you know, rather than what you're trying to deduce. The nice thing about having all historical and current and future data in one table is that you can: a) trivially review the past, b) trivially create future changes that become effective as time passes. These are non-trivial benefits. The main problem is that the complications added by this model effectively require one to build a SQL-on-SQL system. For some applications this additional complication is probably justifiable by the value of its benefits. > Whether you are keeping copies of the rows in the table, or timestamping SQL > commands, I suggest that for SQLite your timestamps should be unixepoch > stored as a REAL rather than a text expression of seconds. Why REAL instead of INTEGER? Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
