PHP time() vs MySQL UNIX_TIMESTAMP(NOW())

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

PHP time() :

-----
То что программа работает, не означает что она написана правильно!

А смысл? Поля DATETIME , DATE или TIMESTAMP дают кучу возможностей по форматированию и сравниванию даты, а что может простая метка в int поле?

-----
Если вы хотя бы 3-4 раза не решите всё выкинуть и начать заново - вы явно что-то делаете не так.

OrmaJever честно - не могу ответить на твой вопрос, вот не нравится мне чем-то, и все тут

нивкоем случае я не говорю что они плохи, просто мне так больше нравится, привык, приучили

-----
То что программа работает, не означает что она написана правильно!

А можно ещё раз, но без бесполезной здесь функции UNIX_TIMESTAMP, только отнимающей время?

-----
PostgreSQL DBA

Давно перестал хранить метку времени как дату чего-либо. MySQL даёт богатый и гибкий функционал для работы с датой.
Храню дату в формате TIMESTAMP, запись произвожу через CURRENT_TIMESTAMP()

впервые слышу, что NOW возвращает метку
(Добавление)

-----
То что программа работает, не означает что она написана правильно!

В Mysql 5 и выше при хранении даты в TIMESTAMP, она автоматически конвертируется из текущей временной зоны в UTC, а так же конвертируется обратно при получении.
Этим может объясняться то, что запросы с использованием TIMESTAMP будут выполняться медленнее, чем с DATETIME.
Пример бенчмарка:

Кроме этого, существует ограничение в TIMESTAMP, связанное с предельным 32-битным целочисленным значением (известный "кризис 2038-го"), для DATETIME же такое значение будет равно 9999-12-31, что трудно достижимо.
TIMESTAMP при этом имеет полезную возможность в виде обновления (ON UPDATE CURRENT_TIMESTAMP и DEFAULT CURRENT_TIMESTAMP), что может быть важным при определенной бизнес-логике.

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.

EuGen, думаю со временем "кризис 2038" года будет решён, до этого времени БД MySQL переживёт ещё не одну версию, а может быть что то более универсальное придумают.

предпочитаю datetime

во первых напрягает когда БД чего то там конвертит без моего ведлма
во вторых timestamp не дает хранить NULL а иногда это нужно по бизнес логике

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

до этого времени уже все пеерсядем за 64-x битные

-----
То что программа работает, не означает что она написана правильно!

Верно, NOW() - возвращает Y-m-d H:i:s
Вот только TIMESTAMP такую запись сам жуёт.

-----
PostgreSQL DBA

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

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

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.

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

(Отредактировано автором: 25 Октября, 2012 - 20:07:43)