?? 2015-12-30 2:56 GMT+01:00 Richard Hipp <drh at sqlite.org>: > On 12/29/15, Cecil Westerhof <cldwesterhof at gmail.com> wrote: > > I first had the following table: > > CREATE TABLE simpleLog ( > > datetime TEXT NOT NULL PRIMARY KEY DEFAULT CURRENT_TIMESTAMP, > > description TEXT NOT NULL > > ) > > > > ?But datetime then takes 19 bytes. I understood you can also use an > Integer > > or Real and that this should be more efficient. At the moment I have the > > following (I do not expect more as one record in a second): > > CREATE TABLE simpleLog ( > > datetime INT NOT NULL PRIMARY KEY DEFAULT (strftime('%s')), > > description TEXT NOT NULL > > ) > > > > And a select is then done by (in my select minute is precision enough): > > SELECT strftime('%Y-%m-%d %H:%M', datetime, 'unixepoch', 'localtime') > as > > datetime > > , description > > FROM simpleLog > > ORDER BY datetime DESC > > > > Is this a good way to go, or is there a better way? > > What you have should work well. > > If you store the date/times as a floating-point Julian Day Number, you > can omit the 'unixepoch' on query. Use julianday('now') instead of > strftime('%s','now') on the DEFAULT. That seems a little simpler to > me, and you get millisecond resolution on the date/times instead of > just second resolution. But the unix-time format is more familar to > many programmers, and can be stored in 4 bytes instead of 8. >
?A resolution of one second is more as enough in this case and Integer is more efficient as Real. So that is why I choose this solution. If I need a finer resolution I always can redefine? ?the table. Thanks for the feedback. -- Cecil Westerhof