Question

I was reading over an article that shows some really good information and benchmarks about how well the three different MySQL date/time storage options perform.

MySQL DATETIME vs TIMESTAMP vs INT performance and benchmarking with MyISAM

While reading the article you start to get the idea that using ints are just a waste and you should instead go with MySQL Datetime or Timestamp column types.

However, towards the end of the article he does one more test not using MySQL functions and you suddenly see that straight INT’s are 2x as fast as the two MySQL options when searching by unix timestamps.

So it suddenly dawned on me – duh, what do PHP apps all use? time()! Almost every php application bases their logic off of the Unix Epoch. Which means that most queries for results in a certain time start off based on time() and then are converted to work with MySQL’s fields.

This leaves me with the following:

1. Unix Timestamps stored as INT’s are
   faster, take less space, and work
   natively with PHP’s time() based
   calculations.

2. MySQL Date types are more suited to
   operations and logic from the MySQL
   side.

3. For the time being both Unix And
   MySQL Timestamps only work until
   2037 which means that you must use a
   datetime field for larger dates in
   the future.

4. MySQL commands like date = NOW() can lag when
   using replication causing data inconsistencies.

So applying this to real life we see that answer
that these results given that most really DBA’s would use a better engine like PostgreSQL – is there arny

However, most apps that would be to the level of using DB logic would probably go with PostgreSQL. Which means that all the rest of us programmers only use MySQL for a storage tank for our data (you know it’s true) which makes keeping the fields as small, fast, UNIX INT’s seem like it is actually the best option.

So what do you guys think?

Are timestamps really more suited to PHP apps than the MySQL date fields?

Answer 1

MySQL’s date format has no year 2038 problem.

MySQL’s dates are reliable from the year 1000 to the year 9999, whereas Unix timestamps can screw up after 2038 or before 1902 unless everything in your system is 64-bit.

If you’re using PHP, however, this can be moot: PHP uses unix timestamps for dates and times throughout most of its date and time functions and unless you are using a 64-bit build it will have the same limitation.

You’d be using the field type that was intended for this purpose.

If you care. Putting date into an INT field as a unix timestamp is not as self-describing; you can’t look at the data without converting it in the appropriate way. But that may make no difference to you.

The flip side of this, given that you’re using PHP, is that once you get the time into PHP you’d have to convert it back to a Unix timestamp anyway to do anything useful with it, because to PHP, Unix timestamps are native.

Edit:

Back when I wrote this answer, I didn’t use PHP’s DateTime class. Using the DateTime class removes any need to use Unix timestamps, and removes the 32-/64-bit issues. Thanks to Charles’ comment below for pointing out a good way to use this.