On Apr 16, 2012, at 5:04 PM, Simon Slavin 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>
>
> Unfortunately he uses terms aimed at an academic mathematical understanding
> of attributes (relvars), which are difficult to understand if you're just a
> programmer at the rock face. What it comes down to is that if the only data
> you have is the result of SQL commands you don't have enough data to
> understand the facts implicit in the contents of your tables.
>
> 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.
I absolutely don't get any of the above. Why is "keeping the data" worse than
keeping the commands? I am not even sure what is a command vs. what is a data.
A SQL command has data embedded in it. I mean, if I have
UPDATE t
SET name = 'foo', val = 3.1415
WHERE id = 22;
which part was the command and which part was the data?
Why is just making a copy of the existing row with id = 22 and then modifying
the copy not good enough? I don't have to deduce anything. All I have to do is
make a copy of any row that is "more than a trivial update". Theoretically I
could do that with every single table, and if the id didn't change (assuming I
had a PK that was different from the id, say, a composite PK), then I could
reconstruct exact queries easily.
>
> 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.
>
Yes, that is a useful advice.
Thanks,
--
Puneet Kishor
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
