Временная метка Unix VS datetime

Возможный дубликат:
datetime vs timestamp?

У меня есть таблица Mysql, которая имеет столбец add_date. Он отслеживает дату/время, когда запись была добавлена в базу данных.

Запросы, основанные на этой таблице:

Показывать, когда запись была добавлена в формате: 2 часа назад, 4 недели назад, 1 год назад и т.д.
Разрешить пользователям поиск записей, вставленных в любой день/месяц/год. Таким образом, пользователю может быть разрешено выбирать записи только в 2009 году.

Что было бы лучше в этом случае - временная метка unix или datetime?

Сейчас я использую оба, но поскольку таблица будет иметь миллионы записей с течением времени, наличие обоих столбцов может повлиять на размер базы данных.

Временная метка Unix, по-видимому, лучше для преобразования в формат 2 hours назад в PHP, а также независимая от часовой пояс. Но datetime лучше читается, и запрос на конкретную дату/время/год кажется проще.

Ваше предложение?

Ответ 1

Если у вас есть выбор, я бы сказал, что выходите на даты mySQL.

Вам не придется заботиться о проблема с датами > s
Вы можете легко запросить промежутки времени, используя функции даты mySQL (BETWEEN(), DATE_ADD и т.д.)
Запросы, связанные с датой, будут намного быстрее, особенно когда у вас есть миллионы записей, потому что вам не придется использовать FROM_UNIXTIME(), которые могут быть дорогими в больших запросах
Воспроизведение дочернего элемента для преобразования полей DATE в временные метки UNIX при необходимости.

Ответ 2

Я бы пошел для форматов mysql, просто потому, что mysql имеет множество функций datetime, чтобы использовать, что с timestamp будет стоить вам другого преобразования.

но поскольку таблица будет иметь миллионы записей с течением времени, имеющих как столбцы могут влиять на размер базы данных.

о, мой.
вы действительно обеспокоены в 4 дополнительных мегабайтах пространства?

Ответ 3

Вы можете получить лучшее из обоих миров, используя временную метку unix и функцию MySQL from_unixtime() для преобразования результата в формат даты и времени, где это необходимо.