Кто в каком виде хранит дату в мускуле?

[Dromok]

Всю жизнь использовал int. Но почти на каждом шагу слышу, что это плохой тон. Мол лучше использовать timestamp.
Но чем это лучше? Кроме сразу человекопонятного вывода даты не вижу никаких других преимуществ. Автоматическое обновление даты на стороне мускула мне как-то особо не нужно так как есть в йии TimestampBehavior. Функциями для работы даты на стороне мускула никогда не пользовался, по мне так удобнее с датой сделать всё что нужно на стороне PHP.
К тому же с точки зрения производительности наверное всё-таки int предпочтительнее, так как в случае большого количества данных мускулу не требуется никаких дополнительных обработок делать (что происходит при timestamp).
У кого какое мнения? А то я что-то не могу толком определиться казалось бы в таком простом вопросе. Чем всё-таки timestamp лучше и лучше ли чем int?

[jakiro]

Тоже раньше задавался вопросом, но уже давно использую datetime или date, и для восприятия лучше и база спокойно умеет с ними работать. А timestamp при безудержном желании получить не долго

[zelenin]

вы запутаете людей int vs timestamp, т.к. в не-mysql мире timestamp == unixtime.
Речь идет о unixtime vs datetime/вариации.

[zelenin]

Функциями для работы даты на стороне мускула никогда не пользовался, по мне так удобнее с датой сделать всё что нужно на стороне PHP.

и это норм. но на стороне php можно в любом формате работать с датой, в прочем как и на стороне БД - не аргумент. А вот то что вам удобнее работать с датой в человекоНЕчитаемом int, а не в datetime, странно.

К тому же с точки зрения производительности наверное всё-таки int предпочтительнее, так как в случае большого количества данных мускулу не требуется никаких дополнительных обработок делать (что происходит при timestamp).

вопрос изучили или так, наобум? давайте так: сделайте тесты и, если ваше приложение замедлится хотя бы на 1%, будем разговаривать о производительности. Если нет просадки производительности на существенную цифру, то сначала мы говорим об удобстве и красоте кода.

У кого какое мнения? А то я что-то не могу толком определиться казалось бы в таком простом вопросе. Чем всё-таки timestamp лучше и лучше ли чем int?

дата должна храниться в дате. есть стандарт даты iso8601, вариант которой (Y-m-d H:i:s в php-нотации) поддерживают все вендоры (mysql, postgres итд). И это кстати не mysql timestamp, а mysql datetime

[Dromok]

Тоже раньше задавался вопросом, но уже давно использую datetime или date, и для восприятия лучше и база спокойно умеет с ними работать. А timestamp при безудержном желании получить не долго

Благодарю. Но datetime сразу отсеял, так как всё-таки 8 байт против 4 байт. Имхо timestamp всё-таки предпочтительнее.

Речь идет о unixtime vs datetime/вариации.

Речь всё-таки о int vs timestamp. Datetime я даже не рассматриваю, так как в этом случае даже куча путаницы с временными зонами будет, да и как выше уже отметил занимает места в два раза больше.
А тестов в интернете достаточно. Если хранить дату как int и запросы все посылать именно число, то это быстрее чем работа с датой на стороне мускула.

Я знаю, что Sam Dark раньше только в int хранил дату. Интересно сейчас также делает?

[samdark]

Да.

[Dromok]

Да.

Можно пару слов почему именно в int?
Я тоже всегда так делал, но чота недавно пообщался с командой программеров, которые крупный проект пишут и говорят это плохой тон в int хранить дату.

[zelenin]

Да.

Можно пару слов почему именно в int?
Я тоже всегда так делал, но чота недавно пообщался с командой программеров, которые крупный проект пишут и говорят это плохой тон в int хранить дату.

я уже привел аргументацию выше: дата в дате и человекочитаемость.

[Dromok]

Выдержка из книги издательства O'Reilly "MySQL Оптимизация производительности":

... мы рекомендуем пользоваться типом TIMESTAMP, если это возможно, поскольку с точки зрения занимаемого места на диске он гораздо эффективнее, чем DATETIME. Иногда временные метки UNIX сохраняют в виде целых чисел, но обычно это не дает никаких преимуществ. Поскольку такое представление часто неудобно, мы не советуем так поступать.

В новом проекте попробую использовать Timestamp. Если что, то на int всегда можно вернуться.

[R3D3]

А тестов в интернете достаточно. Если хранить дату как int и запросы все посылать именно число, то это быстрее чем работа с датой на стороне мускула.

Приведите пожалуйста конкретные ссылки. А то я полез гуглить и натолкнулся на обратные результаты

[R3D3]

Функциями для работы даты на стороне мускула никогда не пользовался, по мне так удобнее с датой сделать всё что нужно на стороне PHP.

Уже давно не работал с mysql, но так, навскидку задача: нужно сделать выборку всех записей из таблицы за последние два года, но только за субботу и воскресенье. В случае если у нас время записи created_at хранится в datetime/timestamp, то можно написать
WHERE DAYOFWEEK(created_at) IN (6,7)

А как будет выглядеть код если время хранится в int ? Думаю, что сложнее.

[zelenin]

Выдержка из книги издательства O'Reilly "MySQL Оптимизация производительности":

... мы рекомендуем пользоваться типом TIMESTAMP, если это возможно, поскольку с точки зрения занимаемого места на диске он гораздо эффективнее, чем DATETIME. Иногда временные метки UNIX сохраняют в виде целых чисел, но обычно это не дает никаких преимуществ. Поскольку такое представление часто неудобно, мы не советуем так поступать.

В новом проекте попробую использовать Timestamp. Если что, то на int всегда можно вернуться.

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

[zelenin]

Функциями для работы даты на стороне мускула никогда не пользовался, по мне так удобнее с датой сделать всё что нужно на стороне PHP.

Уже давно не работал с mysql, но так, навскидку задача: нужно сделать выборку всех записей из таблицы за последние два года, но только за субботу и воскресенье. В случае если у нас время записи created_at хранится в datetime/timestamp, то можно написать
WHERE DAYOFWEEK(created_at) IN (6,7)

А как будет выглядеть код если время хранится в int ? Думаю, что сложнее.

в пхп вычислить это можно достаточно быстро, хоть и многословнее, но итоговый sql будет включать огромный in с диапазонами.

[vitalik1183]

храню в DATETIME - полет нормальный.

[Dromok]

А тестов в интернете достаточно. Если хранить дату как int и запросы все посылать именно число, то это быстрее чем работа с датой на стороне мускула.

Приведите пожалуйста конкретные ссылки. А то я полез гуглить и натолкнулся на обратные результаты

По вашей же первой ссылке запрос вида select SQL_NO_CACHE count(id) from test_int where datetime > 1800 AND datetime < 2100; быстрее всех остальных на порядок. Об этом я и говорил, что если в запросах передавать чисто числа (то есть вся обработка дат на стороне PHP), то такие запросы намного быстрее тех, где вы передаете дату.

[Nerf]

Не вижу преимуществ хранения в int.
С datetime есть проблемы, когда нужно поддерживать часовые пояса. Если их нет, то выбор очевиден.
timestamp конвертирует даты исходя из настроек подключения, что удобно при использовании разных временных зон.

в пхп вычислить это можно достаточно быстро, хоть и многословнее, но итоговый sql будет включать огромный in с диапазонами.

WHERE DAYOFWEEK(FROM_UNIXTIME(created_at)) IN (6,7), где created_at - int (timestamp и так работает)

ПС: Как вы даты(без времени) храните в int?

[Dromok]

ПС: Как вы даты(без времени) храните в int?

Ответ очевиден - даты храним вместе с временем

[zelenin]

Не вижу преимуществ хранения в int.
С datetime есть проблемы, когда нужно поддерживать часовые пояса.

какие например?

WHERE DAYOFWEEK(FROM_UNIXTIME(created_at)) IN (6,7), где created_at - int (timestamp и так работает)

и ждем пока mysql все 2000000 строк сконвертирует в datetime

[R3D3]

По вашей же первой ссылке запрос вида select SQL_NO_CACHE count(id) from test_int where datetime > 1800 AND datetime < 2100; быстрее всех остальных на порядок. Об этом я и говорил, что если в запросах передавать чисто числа (то есть вся обработка дат на стороне PHP), то такие запросы намного быстрее тех, где вы передаете дату.

Аа ну так то да, согласен, быстрее. Но простыми числами неудобно оперировать в нетривиальных запросах шо пипец Обычно работа с датой не ограничивается только выборкой больше/меньше, а еще надо выдрать из времени месяц/день недели, сгруппировать, сагрегировать и т.д.
В простых случаях выборок + хайлоад я бы и выбрал int, но только и только в таких простых случаях.

в пхп вычислить это можно достаточно быстро, хоть и многословнее, но итоговый sql будет включать огромный in с диапазонами.

Вот именно В результате получаются адские динамически генерируемые на бэкенде запросы, что может очень сильно сказаться на производительности. В то время как во всяких крутых базах например можно даже индекс построить по выражению DAYOFWEEK и получить супербыструю выборку.

WHERE DAYOFWEEK(FROM_UNIXTIME(created_at)) IN (6,7), где created_at - int (timestamp и так работает)

Вообще конечно читерство Так-то в общем случае мы функцией FROM_UNIXTIME приводим int в нужный нам формат даты-времени и дальше уже можем полноценно использовать все встроенные datetime функции, но встает очевиднейший вопрос - почему бы тогда уж сразу не хранить в виде timestamp чтобы каждый раз не конвертировать?

[Nerf]

Ответ очевиден - даты храним вместе с временем

Код: Выделить всё

date_default_timezone_set('Pacific/Midway');
$timestamp = strtotime('01.01.1970'); // 39600
echo date('r', $timestamp); // Thu, 01 Jan 1970 00:00:00 -1100
date_default_timezone_set('Pacific/Enderbury');
echo date('r', $timestamp); // Wed, 31 Dec 1969 23:00:00 -1200  

Могут и не поздравить

какие например?

С часовыми поясами Иногда надуманные. База вернет, то что сохранили. Если правильно не отформатировать, то на фронте мб дата в будущем например, не?

и ждем пока mysql все 2000000 строк сконвертирует в datetime

Это будет дольше, чем "огромный in с диапазонами"?! Как вы этот in представляете, не могу сходу понять?

встает очевиднейший вопрос - почему бы тогда уж сразу не хранить в виде timestamp чтобы каждый раз не конвертировать?

Не знаю, в int не храню. Вопрос к адептам лучше перенаправить.