Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Форумы портала PHP.SU :: Версия для печати :: PHP time() vs MySQL UNIX_TIMESTAMP(NOW())
Форумы портала PHP.SU » » Работа с СУБД » PHP time() vs MySQL UNIX_TIMESTAMP(NOW())

Страниц (1): [1]
 

1. KingStar - 25 Октября, 2012 - 18:37:17 - перейти к сообщению
Я не знаю почему, но я всегда сохраняю дату в БД в unix-формате (может это покажется странным - никогда не храню в DATETIME , DATE или TIMESTAMP). И вот чет мне захотелось устроить fight между php и mysql, а именно проверить скорость обновления в БД таблицы с полем int(10) UNSIGNED. Тест проводился в цикле for в 1000 итераций по 5 раз.

PHP time() :
PHP:
скопировать код в буфер обмена
  1. UPDATE `table` SET `time` = ".time()." WHERE `id` = 1

Результат:

12.686094045639
12.703804016113
12.533060073853
12.259868860245
12.728137969971




MySQL UNIX_TIMESTAMP(NOW()) :
PHP:
скопировать код в буфер обмена
  1. UPDATE `table` SET `time` = UNIX_TIMESTAMP(NOW()) WHERE `id` = 1

Результат:

14.815867185593
14.972531080246
12.894811153412
14.820999145508
14.356331110001
2. OrmaJever - 25 Октября, 2012 - 18:45:54 - перейти к сообщению
А смысл? Поля DATETIME , DATE или TIMESTAMP дают кучу возможностей по форматированию и сравниванию даты, а что может простая метка в int поле?
3. KingStar - 25 Октября, 2012 - 18:52:03 - перейти к сообщению
OrmaJever честно - не могу ответить на твой вопрос, вот не нравится мне чем-то, и все тут Хм

нивкоем случае я не говорю что они плохи, просто мне так больше нравится, привык, приучили Подмигивание
4. Мелкий - 25 Октября, 2012 - 18:53:06 - перейти к сообщению
А можно ещё раз, но без бесполезной здесь функции UNIX_TIMESTAMP, только отнимающей время?
5. Okula - 25 Октября, 2012 - 18:54:12 - перейти к сообщению
Давно перестал хранить метку времени как дату чего-либо. MySQL даёт богатый и гибкий функционал для работы с датой.
Храню дату в формате TIMESTAMP, запись произвожу через CURRENT_TIMESTAMP()
6. KingStar - 25 Октября, 2012 - 18:57:26 - перейти к сообщению
Мелкий пишет:
А можно ещё раз, но без бесполезной здесь функции UNIX_TIMESTAMP, только отнимающей время?


впервые слышу, что NOW возвращает метку Не понял Не понял Не понял
(Добавление)
Цитата:
в БД таблицы с полем int(10)
7. EuGen - 25 Октября, 2012 - 19:02:46 - перейти к сообщению
В Mysql 5 и выше при хранении даты в TIMESTAMP, она автоматически конвертируется из текущей временной зоны в UTC, а так же конвертируется обратно при получении.
Этим может объясняться то, что запросы с использованием TIMESTAMP будут выполняться медленнее, чем с DATETIME.
Пример бенчмарка:

Кроме этого, существует ограничение в TIMESTAMP, связанное с предельным 32-битным целочисленным значением (известный "кризис 2038-го"), для DATETIME же такое значение будет равно 9999-12-31, что трудно достижимо.
TIMESTAMP при этом имеет полезную возможность в виде обновления (ON UPDATE CURRENT_TIMESTAMP и DEFAULT CURRENT_TIMESTAMP), что может быть важным при определенной бизнес-логике.
8. Okula - 25 Октября, 2012 - 19:14:48 - перейти к сообщению
EuGen, думаю со временем "кризис 2038" года будет решён, до этого времени БД MySQL переживёт ещё не одну версию, а может быть что то более универсальное придумают.
9. caballero - 25 Октября, 2012 - 19:18:42 - перейти к сообщению
предпочитаю datetime

во первых напрягает когда БД чего то там конвертит без моего ведлма
во вторых timestamp не дает хранить NULL а иногда это нужно по бизнес логике
10. KingStar - 25 Октября, 2012 - 19:23:18 - перейти к сообщению
Okula пишет:
EuGen, думаю со временем "кризис 2038" года будет решён, до этого времени БД MySQL переживёт ещё не одну версию, а может быть что то более универсальное придумают.


до этого времени уже все пеерсядем за 64-x битные Радость Радость Радость
11. Мелкий - 25 Октября, 2012 - 19:41:09 - перейти к сообщению
KingStar пишет:
впервые слышу, что NOW возвращает метку

Верно, NOW() - возвращает Y-m-d H:i:s
Вот только TIMESTAMP такую запись сам жуёт.
12. EuGen - 25 Октября, 2012 - 19:54:31 - перейти к сообщению
Мелкий пишет:
Вот только TIMESTAMP такую запись сам жуёт.

Порождая, кстати, конвертацию при сравнении (еще один пункт в потерю быстродействия, если уж быть придирчивым)
Okula пишет:
а может быть что то более универсальное придумают

Придумают, разумеется. Скорее всего, введут более высокую разрядность. Я лишь описал текущий тип данных.
13. dubasua - 25 Октября, 2012 - 20:07:01 - перейти к сообщению
Лично я всегда создаю поле int(10). А потом конвертиш как нужно под разные нужды. И знаний особо никаких не нужно. И зачем держать в голове кучу функция lдля работы с датой, которые легко решаются простыми арифметическими действиями.
OrmaJever пишет:
А смысл? Поля DATETIME , DATE или TIMESTAMP дают кучу возможностей по форматированию и сравниванию даты, а что может простая метка в int поле?

Лично мне на моей практике ни разу не выпадало такое, что нельзя было бы решить обычным INT(10). Ну мне наоборот так проще, допустим я не знаю как вычислить количество дней между двумя датами в формате DATE, а в INT(10) все просто, от большего отнял меньшее, перевел разницу секунд в дни и все. И так решается большинство задач. Короче я считаю его "Дедовским" и безотказным методом, я ставлю плюс на сторону INT(10)

 

Powered by ExBB FM 1.0 RC1