Дата MySQL или время PHP?

Question

Обычно я храню даты как целые числа, используя PHP time() функцию в базе данных MySQL, а не формат даты MySQL просто потому, что легче манипулировать, когда я возвращаю ее назад, но есть ли у этого недостатки?

Answer 1

Диапазон:

Всегда есть очевидный недостаток: диапазон, который вы можете хранить, ограничен с 1970 по 2038 год. Если вам нужно хранить даты вне этого диапазона, вам, как правило, нужно использовать другой формат. Наиболее распространенный случай, который я нашел, это касается дат рождения.

Дискретность:

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

Индексы:

Хорошая техническая причина для использования типов дат заключается в том, что в некоторых случаях он допускает индексированный запрос, чего нет в метках времени Unix. Рассмотрим следующий запрос:

SELECT * FROM tbl WHERE year(mydate_field) = 2009;

Если mydate_field имеет собственный тип даты и в поле есть индекс, этот запрос будет фактически использовать индекс, несмотря на вызов функции. Это практически единственный раз, когда mysql может оптимизировать вызовы функций в таких полях. Соответствующий запрос в поле временной метки не сможет использовать индексы:

SELECT * FROM tbl WHERE year(from_unixtime(mytimestamp_field)) = 2009;

Если подумать немного, то есть способ обойти это. Этот запрос делает то же самое, и сможет использовать оптимизацию индекса:

SELECT * FROM tbl WHERE mytimestamp_field > unix_timestamp("2009-01-01") AND mytimestamp_field < unix_timestamp("2010-01-01");

Расчеты:

Обычно я сохраняю даты как время Unix, несмотря на недостатки. Это на самом деле не основано на его достоинствах, а скорее потому, что я к этому привык. Я обнаружил, что это упрощает некоторые вычисления, но усложняет другие. Например, очень сложно добавить месяц к метке времени Unix, так как количество секунд в месяце варьируется. Это очень легко с помощью функции mysql DATE_ADD (). Тем не менее, я думаю, что в большинстве случаев это действительно упрощает вычисления. Например, довольно часто вы хотите выбрать сообщения, скажем, за последние два дня. Если поле содержит метку времени Unix, это можно легко сделать, просто выполнив:

SELECT * FROM tbl WHERE mytimestamp_field > time() - 2*24*3600;

Это, вероятно, дело вкуса, но лично я считаю это быстрее и проще, чем вспоминать синтаксис такой функции, как DATE_SUB ().

Часовые пояса:

Штампы Unix не могут хранить данные часового пояса. Я живу в Швеции с одним часовым поясом, так что это не проблема для меня. Однако это может быть серьезной болью, если вы живете в стране, которая охватывает несколько часовых поясов.

Answer 2

Одним из недостатков является то, что вы не сможете манипулировать и запрашивать эти даты с использованием функций SQL.

Answer 3

Раньше я делал то же самое, но теперь я сохраняю его как MySQL DateTime - просто потому, что при просмотре необработанных данных в базе данных я могу легко их интерпретировать.

Кроме этого, возможно, легче работать с данными на других языках, которые не используют метку времени UNIX так сильно (как в PHP), но в любом случае не так уж и сложно.

Answer 4

Вы можете определить автоматическое обновление для меток времени MySQL в определении таблицы.
http://dev.mysql.com/doc/refman/5.0/en/timestamp.html

Answer 5

Временная метка UNIX имеет очевидные ограничения в отношении диапазона дат, которые вы можете хранить.

Я также сейчас всегда использую DATETIME поля. Вы можете выполнять большую часть математики DATE, используя SQL, чтобы вы могли извлечь полезную информацию, такую ​​как DATEDIFF, между настоящим моментом и сохраненной датой, вообще не используя PHP.

Answer 6

Есть много недостатков:

• Недостаток точности; Время Unix с точностью до секунды и только для дат между 1901-12-13 и 2038-01-19 при использовании типичного 32-разрядного целого числа
• Вы не можете использовать какие-либо встроенные функции базы данных для запроса или манипулирования данными
• Вы не можете хранить часовой пояс

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

Answer 7

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

Преимущества

• Всегда хранится в UTC часовом поясе (если у вас есть серверы в нескольких часовых поясах, преобразование не требуется).
• Приложения преобразуют их в предпочтительный часовой пояс (это происходит только один раз, на последнем возможном уровне).
• Не строки (они огромны по сравнению с целыми числами).
• Меньше вычислений в базе данных (Материал типа created <19345345345-24 * 60 * 60 рассчитывается один раз). </li>

EDIT: Временные метки MySQL хранятся не как строки, а при извлечении из базы данных, которые преобразуются в строки. Тип DATETIME не изменяется MySQL, что означает, что если вы поместите дату в базу данных, вы получите то же самое.

Если у вас есть посетители на веб-сайте из другого часового пояса, вам придется конвертировать даты как строка-> строка вместо целого числа-> строка). В некоторых странах даты - это не просто числа (например, во Франции это Mardi 15 mai 2012. Я предпочитаю делать это в PHP или JS. Я думаю, что целочисленное преобразование в simpe-строке быстрее чем Integer-> String-> String. Плюс нет головной боли при переходе на серверы в другой стране.

Поддельные недостатки :

• Я считаю, что ограниченный диапазон меток времени Unix на самом деле не ограничен. Отметка времени - это целое число в базе данных, поэтому вы можете настроить размер. По умолчанию целое число unsigned равно int(10), что означает, что вы можете хранить числа до 4294967295, но его ограничения не являются фиксированными, поэтому мы можем легко изменить int(10) int на int(16) bigint

Answer 8

Небольшая потеря деталей. Переменная MySQL Datetime может быть очень точной.

Кроме того, если вам нужно сравнить даты в вашей базе данных, в формате даты есть некоторые встроенные функции, которые вы не сможете использовать.

Answer 9

Только пару я могу придумать:
* Если другое приложение не-php должно использовать базу данных, это будет трудный формат для чтения.
* Если вы хотите выполнить какую-либо работу на основе SQL в эти даты (например, добавить месяц или получить все значения для определенного года и т. Д.), Это будет более трудным.

Answer 10

Это не так уж плохо, но вы потеряете некоторые встроенные функции, такие как:

выберите * из таблицы1, где dateColumn = getDate () - 30

Используйте datetime, если можете!