Yii Framework

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

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

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

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

zelenin писал(а):Речь идет о unixtime vs datetime/вариации.

Sam Dark писал(а):Да.

Dromok писал(а):

Sam Dark писал(а):Да.

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

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

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

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

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

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

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

R3D3 писал(а):

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

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

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

R3D3 писал(а):

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

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

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

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

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

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

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

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

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

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

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

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