I've been using the unix timestamp all my life.
I like it because it's easy to compare, it's fast because I store it as an integer. And since I'm using PHP, I can get any date/time format with date() function from the unixtimestamp.
Now, some people are saying that it's best to use the DATETIME format. But besides the more suited name, I don't see any advantages.
Is it indeed better to use DATETIME, if so, what are the advantages?
Thanks.
@Smita V, the inefficient query to which you refer is only so because you're applying your conversion function incorrectly to every table row, where you should apply it to the condition itself. So instead of
, which converts every row on the table to compare it to the date you've got. You should use
Doing it this way WILL use the appropriate table indexes.
@treznik a while ago I moved from a uts integer to a datetime or timestamp data types, for the reasons mentioned above, in that they're much easier to read and manipulate (I do quite a lot of direct table access). However I've lately started to re-think this approach for two reasons:
I'm still trying to figure out the answer to this, myself.
Using database datetime is more efficient because every time you need to query you would need to apply from_unixtime() function to extract data from unix datetime col of the table. Using this function in where clause will completely ignore any index usage.
say my query is:
select col1,col2,colUnixdatetime from table where colUnixdatetime between wtvdate1 and wtvdate2
I would need to run:
select col1,col2,colUnixdatetime from table where From_Unixtime(colUnixdatetime) between wtvdate1 and wtvdate2
This above query will completely ignore any indexes, well there is no use of indexes here as they will never be used coz I will always have to use a function to get the real date time.
Any in-built function used on LHS of condition in a where clause would not use any indexes and if you have a HUGE table, your query will take longer.
Easier maintenance is a plus. Seeing the actual date when you do:
is pretty nice.
I've also been a huge fan of the unix timestamp all my life. But I think the correct answer is: "depends". I recently did a single table database where I wanted to only list URLs. There would be a date field, but the date field is purely for sorting. I.e order by last_crawled. Which means I will never use any built-in date functions on that field. It is merely an easy way to get the oldest entries first and I will never apply date functions to this field. Now, had I made this a date field, I would have lost out on two things:
However, for another system I had to store transactional information. This made using internal mysql date functions possible which turned out to be very useful when we had to start doing reports.
Easier to compare, and mysql provides a lot of date functions.
If you store dates as Unix timestamps in the database, you're giving yourself the heavy lifting. You have to convert them to the formats you want to use, you have to do the calculations between date ranges, you have to build the queries to get data in a range. This seems counter-intuitive- surely your "programmer time" is best spent solving real problems?
It seems much better practice to store dates and times in the proper format that MySQL has available, then use the database functions to create the queries for the data you want. The time you would waste doing all the convertions and mucking about is massive compared to the afternoon spent reading (and understanding) 11.6 MySQL Date and Time Functions