Поля даты и времени метки MySQL лучше для приложений PHP, чем целочисленные значения Unix?

Question

Я читал статью, в которой показана действительно хорошая информация и тесты производительности трех различных вариантов хранения даты / времени MySQL.

MySQL DATETIME против TIMESTAMP против производительности INT и сравнительный анализ сMyISAM

Читая статью, вы начинаете понимать, что использование целых чисел - это просто трата, и вам следует вместо этого использовать типы столбцов MySQL Datetime или Timestamp.

Однако в направленииВ конце статьи он делает еще один тест, не используя функции MySQL, и вы внезапно видите, что прямые значения INT в 2 раза быстрее, чем две опции MySQL при поиске по меткам времени unix .

Так что это неожиданнодо меня дошло - дух, что все приложения PHP используют? time ()! Почти каждое php-приложение основывает свою логику на Unix Epoch.Это означает, что большинство запросов на результаты в определенное время начинаются на основе time () , а затем преобразуются для работы с полями MySQL .

. Это оставляет мне следующее:

1. Отметки времени Unix, хранящиеся в виде INT, работают быстрее, занимают меньше места и изначально работают с вычислениями PHP на основе времени ().

2. Типы MySQL Date больше подходятк операциям и логике со стороны MySQL.

3. В настоящее время временные метки Unix и MySQL работают только до 2037 года, что означает, что вы должны использовать поле datetime для больших дат в будущем.

4. Такие команды MySQL, как date = NOW(), могут отставать при использовании репликации, вызывая несоответствия данных.

Таким образом, применяя это к реальной жизни, мы видим ответ, что эти результаты, учитывая, что на самом деле администраторы баз данных будут использовать более совершенный движок, такой как PostgreSQL, - есть ли у них арни

Однакоприложения, которые были бы на уровне использования логики БД, вероятно, пойдут с PostgreSQL.Это означает, что все остальные программисты используют MySQL только для резервуара для хранения наших данных (вы знаете, что это правда), что делает поля маленькими и быстрыми, UNIX INT кажутся действительно лучшимивариант.

Так что вы, ребята, думаете?

Действительно ли метки времени больше подходят для приложений PHP, чем поля даты MySQL?

Answer 1

В формате даты MySQL нет проблем с 2038 годом.

Даты MySQL надежны, начиная с 1000 по 9999 год, тогда как метки времени Unix могут испортиться после 2038 или до 1902 года, если тольков вашей системе она 64-битная.

Однако, если вы используете PHP, это может быть спорным: PHP использует метки времени unix для дат и времени в большинстве своих функций даты и времени, и если вы не используете64-битная сборка будет иметь то же ограничение.

Вы будете использовать тип поля, предназначенный для этой цели.

Если вам не все равно.Помещение даты в поле INT в качестве метки времени Unix не является самоописанием;Вы не можете смотреть на данные, не преобразовав их соответствующим образом.Но это может не иметь никакого значения для вас.

Обратная сторона этого, учитывая, что вы используете PHP, заключается в том, что, как только вы получите время на PHP, вам придется преобразовать его обратно в метку времени Unix.в любом случае, делать с ним что-нибудь полезное, потому что для PHP временные метки Unix являются родными.

Редактировать:

Когда я писал этот ответ, я не использовал PHP-класс DateTime.Использование класса DateTime устраняет необходимость использования меток времени Unix и устраняет 32- / 64-битные проблемы.Спасибо комментарию Чарльза ниже за то, что он указал хороший способ использовать это.

Answer 2

Хороший и открытый вопрос.Я вижу, вы перфекционист.Я тоже.

Но, как и почти все в программировании и жизни, это зависит от того, как оно будет соответствовать вашей проблеме.

Если производительность действительно критическая, вам следуетиспользуйте метки времени UNIX.

Но я действительно не думаю, что это так.Я говорю вам, почему.Это потому, что я разделяю ту же точку зрения, что и Расмус Лердорф.PHP - это язык сценариев, который предоставляет множество возможностей для малого и среднего бизнеса.

Для действительно очень важных / больших приложений, где масштабируемость и производительность действительно важны, вам вообще не следует использовать PHP + MySQL.

Java или C ++ - лучшие решения.Я думаю, что большинство парней здесь спросят: «Что не так с PHP, ваш ублюдок ?!».Ну, много вещей на самом деле.Некоторое время я работал тестером производительности и говорю, что разработчики должны помнить, что ваш любимый язык не всегда является лучшим решением для каждой проблемы.

Позвольте мне привести вам пример.Критическое математическое / физическое приложение.Просто нужен номер для анализа феномена.Вы можете сделать это на Shell Script, и C. C будет работать намного лучше.Смотрите, выбор наиболее подходящего языка и инструментов для решения вашей проблемы - это ответ на ваш правильный ответ.

Давайте вернемся к MySQL, PHP и типам данных.Если вы используете их, Полагаю, приложение не такое уж большое и не полно бизнес-правил (если оно такое большое, вы должны рассмотреть некоторые скомпилированные языки, и если это так важно, вам следует подуматьиспользуя PostgreSQL или Oracle).

И в этом случае важна скорость создания приложения.Если вы сделаете это, я думаю, что хороший способ начать - основывать поля формы на метаданных базы данных.Это может помочь вам автоматизировать построение форм.И в этом случае я рекомендую использовать собственные типы баз данных.

Answer 3

Использование различных форматов времени и даты 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 () для даты и времени mktime () для времени и даты

Answer 4

Мне нравится хранить всю логику в одном высокоуровневом домене (это приложение, написанное на php).MySQL - это хранилище данных - как и должно быть.Я предпочитаю использовать класс, такой как http://www.symfony -project.org / plugins / sfDateTime2Plugin , а затем -> dump () или -> get () в любом подходящем формате.Гораздо быстрее и проще писать (и расширять) высокоуровневые манипуляции в области приложения, чем использовать статический интерфейс mysql.

Интерфейс PostgreSQL очищается от MySQL.Но мы все еще говорим о MySQL, потому что он популярен.Что поднимает важный вопрос.При написании кода или проектировании систем часто имеет смысл соблюдать соглашение, даже если оно менее вычислительно эффективно, чем другие менее известные варианты.Это важно, потому что это способствует другому типу эффективности - удобочитаемости для других.Зачастую неэффективность читабельности и понятности объясняет большие бизнес-затраты (и время), чем неэффективность вычислений.Пожалуйста, сделайте попытку и напишите о своих выводах.

Приветствия

Answer 5

Я всегда предпочитаю хранить даты в формате mySQL, поскольку это упрощает сравнение в ваших запросах.В MySQL также есть несколько отличных вариантов форматирования даты: http://www.dan.co.uk/mysql-date-format/

Извините, я должен добавить, я действительно не знаю, какой из них более эффективен по скорости, что было важной частью вашего вопроса.

Answer 6

Если вы используете INT вместо DATETIME, вы теряете гибкость в GROUP по дате, часу или времени, делая различные манипуляции с интервалами.

Вы можете сделать это с помощью INT, используя функцию FROM_UNIXTIME , но ваш запрос будет нечитаемым.

Использование INT вместо DATE делает ваши затраты на программирование в 3 раза больше, чем ваша работа с DATE. Вы безопасно выполняете время, не достаточное для покрытия затрат на программирование. Аппаратное обеспечение дешевле, чем сложное программирование.

Как только мы совершили эту ошибку и сохранили дату в INT. По истечении полугода мы решили сделать около 30 площадок для удобства обслуживания.