Являются ли MySQL datetime и timestamp поля лучше для PHP-приложений, чем unix timestamp ints?
Я читал статью, которая показывает действительно хорошую информацию и тесты о том, насколько хорошо работают три разных варианта хранения даты/времени MySQL.
MySQL DATETIME vs TIMESTAMP vs int производительность и бенчмаркинг с MyISAM
при чтении статьи вы начинаете понимать, что использование ints-это просто отходы, и вместо этого вы должны пойти с типами столбцов MySQL Datetime или Timestamp.
однако, к в конце статьи он делает еще один тест, не используя функции MySQL, и вы вдруг видите, что прямые INT-это 2x так же быстро, как два варианта MySQL при поиске по меткам времени unix.
Так меня вдруг осенило - duh, что все приложения PHP используют? времени()! почти каждое приложение php основывает свою логику от эпохи Unix. Это означает, что большинство запросов для результатов в определенное время начинаются на основе time ()и затем преобразуются для работы с полями MySQL.
У меня следующие:
метки времени Unix, сохраненные как INT быстрее, занимают меньше места, и работают изначально с PHP на основе time() проведенные расчеты.
типы дат MySQL больше подходят для операции и логика из MySQL сторона.
на данный момент Unix и Метки времени MySQL работают только до 2037, что означает, что вы должны использовать поле datetime для больших дат в будущее.
команды MySQL, такие как
date = NOW()может отставать, когда использование репликации, вызывающей несогласованность данных.
поэтому, применяя это к реальной жизни, мы видим, что ответ что эти результаты, учитывая, что большинство действительно DBA будет использовать лучший движок, такой как PostgreSQL - есть arny
однако большинство приложений, которые были бы на уровне использования логики БД, вероятно, пойдут с PostgreSQL. Который означает, что все остальные программисты используют MySQL только для бак для хранения наших данных (вы знаете, что это правда), что делает сохранение полей как маленьких, быстрых, UNIX INT, похоже, что это на самом деле лучший вариант.
Так что вы думаете?
действительно ли метки времени больше подходят для PHP-приложений, чем поля даты MySQL?
6 ответов
формат даты MySQL не имеет проблемы с 2038 годом.
даты MySQL надежны от года 1000 до года 9999, тогда как временные метки Unix могут испортиться после 2038 или до 1902, если все в вашей системе не 64-бит.
Если вы используете PHP, однако, это может быть спорным: PHP использует временные метки unix для дат и времени в большинстве своих функций даты и времени, и если вы не используете 64-разрядную сборку, она будет иметь то же самое ограничение.
вы будете использовать тип поля, который был предназначен для этой цели.
Если вам не все равно. Ввод даты в поле INT в качестве временной метки unix не является самоописанием; вы не можете смотреть на данные без преобразования их соответствующим образом. Но для вас это не имеет значения.
оборотная сторона этого, учитывая, что вы используете PHP, заключается в том, что как только вы получите время в PHP, вам все равно придется преобразовать его обратно в метку времени Unix чтобы сделать что-нибудь полезное с ним, потому что для PHP метки времени Unix являются родными.
Edit:
когда я писал этот ответ, я не использовал класс DateTime PHP. Использование класса DateTime устраняет необходимость использования меток времени Unix и удаляет 32-/64-небольшие проблемы. Спасибо комментарию Чарльза ниже за указание хорошего способа использовать это.
Я всегда предпочитаю хранить даты в формате mySQL, поскольку это упрощает сравнение в ваших запросах. mySQL также имеет отличные параметры форматирования даты: http://www.dan.co.uk/mysql-date-format/
Извините, я должен добавить, я действительно не знаю, какая из них более эффективна с точки зрения скорости, что было важной частью вашего вопроса.
Мне нравится хранить всю логику в одном домене высокого уровня (это приложение, написанное на php). MySQL-это резервуар для хранения,так как он должен оставаться. Я предпочитаю использовать класс, такой какhttp://www.symfony-project.org/plugins/sfDateTime2Plugin а затем - >dump() или ->get () в соответствующий формат в любом случае. Гораздо быстрее и проще писать (и расширять) манипуляции высокого уровня в домене приложения, чем использовать статический mysql взаимодействие.
интерфейс PostgreSQL очищается на MySQL. Но мы все еще говорим о MySQL здесь, потому что он популярен. Что вызывает важное соображение. При написании кода или разработке систем часто имеет смысл соблюдать соглашение, даже если оно менее вычислительно эффективно, чем другие менее известные варианты. Это важно, потому что это способствует другому виду эффективности-удобочитаемости для других. Часто читаемость и понятность неэффективность учет больших бизнес-расходов (и времени), чем вычислительная неэффективность.
Я все за то, чтобы попробовать INTs. Пожалуйста, дайте ему шанс и напишите о своих выводах.
Ура
использование различных форматов времени и даты MySQL позволяет выполнять запросы, которые было бы сложно использовать временные метки Unix.
примером может быть фильтрация данных на основе определенной недели (номер недели) или использование значения в базе данных после добавления или удаления из нее определенного таймфрейма.
MySQL имеет некоторые большие функции для время и дата манипуляции которые хорошо работают с форматами даты, времени и времени.
мы используем PHP/MySQL для большинства из наших сайтов, и мы автоматизируем создание базы данных на PHP объект, код для изменения с PHP на MySQL форматы очень прост:
if($parameter->Type() == DatabaseType::DATETIME)
$parameterValueArray[] = date('Y-m-d H:i:s', $parameter->Value());
elseif($parameter->Type() == DatabaseType::DATE)
$parameterValueArray[] = date('Y-m-d', $parameter->Value());
elseif($parameter->Type() == DatabaseType::TIME)
$parameterValueArray[] = date('H:i:s', $parameter->Value());
MySQL для PHP:
strtotime () для datetime mktime () для времени и даты
хороший и открытый вопрос. Я вижу вы perfeccionist. Я тоже!--1-->
но как почти все в программировании и жизни, это зависит от того, как это будет соответствовать вашей проблеме.
Если производительность действительно критический, вы должны использовать временные метки UNIX.
но я действительно не думаю, что это так. Я скажу тебе почему. Потому что я разделяю ту же точку зрения, что и Расмус Лердорф. PHP-это язык сценариев, который приносит много возможностей для небольших средний бизнес.
для действительно действительно важных / больших приложений, где масштабируемость и производительность действительно важны, вы не должны использовать PHP + MySQL вообще.
Java или C++ - лучшие решения. Я думаю, что большинство парней здесь спросят: "что не так с PHP, твой ублюдок?!". Ну, вообще-то, многое. Я некоторое время работал тестером производительности, и я говорю, что разработчики должны иметь в виду, что ваш любимый язык не всегда является лучшим решением для каждого проблема.
позвольте мне дать вам пример. Критическое приложение по математике / физике. Просто нужен номер для анализа феномена. Вы можете сделать это на Shell Script, и C. C будет работать намного лучше. См., выбор наиболее подходящего языка и инструментов для решения вашей проблемы-это ответ на ваш правильный ответ.
давайте вернемся к MySQL, PHP и типам данных. Если вы используете их,Я думаю приложение не настолько большое, ни полное бизнес-правил (если это это большой, вы бы рассмотрели некоторые скомпилированные языки, и если это так важно, вы должны рассмотреть возможность использования PostgreSQL или Oracle).
и в этом случае имеет значение скорость создания приложения. Если вы это сделаете, я думаю, что хороший способ начать-это база ваших полей метаданных базы данных. Это может помочь вам автоматизировать построение форм. И в этом случае, я рекомендую использовать собственные типы данных.
Если вы используете INT вместо DATETIME, вы теряете гибкость в группе по дате, часу или времени, делая разные манипуляции с интервалами.
вы можете сделать это с помощью INT с помощью функции FROM_UNIXTIME, но ваш запрос будет нечитаемым.
использование INT вместо DATE делает вашу стоимость программирования x3, а затем вашу работу с датой. Вы безопасное время выполнения недостаточно для покрытия затрат на Программирование. Аппаратное обеспечение дешевле, чем сложное программирование.
Как только мы сделали эту ошибку и удерживаем дату в INT. Через полгода мы решаем, чтобы огнеупорные около 30 сайтов для легкого обслуживания.