Paolo Pisati <[email protected]> wrote: > Igor Tandetnik wrote: >> If you use YYYY-MM-DD format consistently, then simple string >> comparison just happens to give the same results as date comparison. >> > i'll take this route, but is it the best choice performance-wise?
Two other good choices well supported by built-in functions are to store a Julian day as a floating point value, or a number of seconds since Unix epoch as integer. Comparison is probably slightly faster on these than with strings (but I suggest you test it to make sure, if you believe performance is critical). If you need to do a lot of date arithmetic like getting the next day, then numeric formats will probably also be faster and easier (you could simply add 1 or 86400 to existing value). But if you need calculations like "same date next month", then you would have to go through strftime anyway, which I suspect works about the same for all formats (but again - if it matters, test). One advantage of the string format is that it's visible to the "naked eye" - when working with the database using generic tools (e.g. for administration or troubleshooting). It's a pain to run ad-hoc queries when the database stores dates as, say, Julian days (which just look like huge numbers, all alike). Igor Tandetnik _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
