Вопросы Теги

MySQL: что лучше всего использовать, Unix TimeStamp или DATETIME [дубликаты]

26
задан Ryan 28 March 2010 в 17:18
поделиться

4 ответа

Метка времени (как PHP, так и MySQL) хранится с использованием 32-битных (т. Е. 4 байтов) целых чисел; это означает, что они ограничены диапазоном дат, который идет с 1970 по 2038 год.

DATETIME не имеют такого ограничения - но хранятся с использованием большего количества байтов (8 байт, если я не ошибаюсь)


После между хранением меток времени, видимых PHP, или меток времени, видимых MySQL:


И, для получения дополнительной информации о типах данных MySQL TIMESTAMP и DATETIME, см. 10.3.1. Типы DATETIME, DATE и TIMESTAMP

19
ответ дан Pascal MARTIN 28 March 2010 в 17:18
поделиться
  • 1
    Плохие Thingsв „ў происходят при использовании чисел со знаком для представления параметров размера. См. мое сообщение. – BlueRaja - Danny Pflughoeft 16 July 2010 в 16:49
  • 2
    Плохие Thingsв „ў происходят при использовании чисел со знаком для представления параметров размера. См. мое сообщение. – BlueRaja - Danny Pflughoeft 16 July 2010 в 16:49
  • 3
    Плохие Thingsв „ў происходят при использовании чисел со знаком для представления параметров размера. См. мое сообщение. – BlueRaja - Danny Pflughoeft 16 July 2010 в 16:49
  • 4
    Плохие Thingsв „ў происходят при использовании чисел со знаком для представления параметров размера. См. мое сообщение. – BlueRaja - Danny Pflughoeft 16 July 2010 в 16:49
  • 5
    Плохие Thingsв „ў происходят при использовании чисел со знаком для представления параметров размера. См. мое сообщение. – BlueRaja - Danny Pflughoeft 16 July 2010 в 16:49

Это действительно зависит. Я приведу 2 примера, где один превосходит другой:

Отметка времени лучше, чем DATETIME, когда вы хотите сохранить сеанс пользователей в базе данных, а время создания сеанса (в формате отметки времени) используется для быстрого поиска строк (с указателем).
Например. Таблица может выглядеть так:
[session_create_time AS Timestamp][IP_address AS 32bit Int][etc...]
Наличие индекса по первым двум столбцам может действительно ускорить ваши запросы. Если у вас есть тип значения DATETIME для поля session_create_time, то это может занять гораздо больше времени. Учтите, что запросы сеанса выполняются каждый раз, когда пользователь запрашивает страницу , поэтому эффективность имеет решающее значение.

DATETIME лучше, чем Timestamp, если вы хотите сохранить дату рождения пользователя или некоторые исторические события, для которых требуется гибкий диапазон времени.

3
ответ дан Dor 28 March 2010 в 17:18
поделиться
  • 1
    @dan04: Нет, первопричина использует подписанный ints, когда необходимо использовать неподписанный ints как size_t (или, более точно, it' s неявное преобразование между числами со знаком/неподписанными) . Конечно, упущение проверить границы является также проблемой. I' ve изменил пример для создания этого более ясным - спасибо. – BlueRaja - Danny Pflughoeft 16 July 2010 в 16:25
  • 2
    @dan04: Нет, первопричина использует подписанный ints, когда необходимо использовать неподписанный ints как size_t (или, более точно, it' s неявное преобразование между числами со знаком/неподписанными) . Конечно, упущение проверить границы является также проблемой. I' ve изменил пример для создания этого более ясным - спасибо. – BlueRaja - Danny Pflughoeft 16 July 2010 в 16:25
  • 3
    @dan04: Нет, первопричина использует подписанный ints, когда необходимо использовать неподписанный ints как size_t (или, более точно, it' s неявное преобразование между числами со знаком/неподписанными) . Конечно, упущение проверить границы является также проблемой. I' ve изменил пример для создания этого более ясным - спасибо. – BlueRaja - Danny Pflughoeft 16 July 2010 в 16:25
  • 4
    @dan04: Нет, первопричина использует подписанный ints, когда необходимо использовать неподписанный ints как size_t (или, более точно, it' s неявное преобразование между числами со знаком/неподписанными) . Конечно, упущение проверить границы является также проблемой. I' ve изменил пример для создания этого более ясным - спасибо. – BlueRaja - Danny Pflughoeft 16 July 2010 в 16:25
  • 5
    @dan04: Нет, первопричина использует подписанный ints, когда необходимо использовать неподписанный ints как size_t (или, более точно, it' s неявное преобразование между числами со знаком/неподписанными) . Конечно, упущение проверить границы является также проблемой. I' ve изменил пример для создания этого более ясным - спасибо. – BlueRaja - Danny Pflughoeft 16 July 2010 в 16:25

Если не оцифровывать записи до 1 января 1970 года, мне нравится эпоха UNIX. Это просто вопрос предпочтения, с целыми числами без знака проще иметь дело при использовании нескольких языков.

Просто имейте в виду, эпоха начинается с 1 января 1970 года. Многие компании были в бизнесе в течение десятилетий, если не дольше, до этого.

1
ответ дан Tim Post 28 March 2010 в 17:18
поделиться
  • 1
    Было довольно распространено во многих системах с 16-разрядным int тип иметь отдельные объекты, которые были больше, чем 32K, но эффективно обрабатывающие объекты, больше, чем 64K, потребуют большего int тип. Проблема с unsigned int состоит в том, что, поскольку Вы вполне справедливо отмечаете, что это используется для выполнения двух непересекающихся ролей (числа по сравнению с алгебраическими кольцами). Я желаю, чтобы C добавил бы новые отдельные типы для натуральных чисел до 2^2^n-1 [например, 65535], натуральных чисел до 2^ (2^n-1)-1 [например, 32767], и алгебраическая кольцевая модификация 2^2^n [например, 65536], с семантикой, которые были лучше в каждом случае. – supercat 22 April 2015 в 15:49
  • 2
    Было довольно распространено во многих системах с 16-разрядным int тип иметь отдельные объекты, которые были больше, чем 32K, но эффективно обрабатывающие объекты, больше, чем 64K, потребуют большего int тип. Проблема с unsigned int состоит в том, что, поскольку Вы вполне справедливо отмечаете, что это используется для выполнения двух непересекающихся ролей (числа по сравнению с алгебраическими кольцами). Я желаю, чтобы C добавил бы новые отдельные типы для натуральных чисел до 2^2^n-1 [например, 65535], натуральных чисел до 2^ (2^n-1)-1 [например, 32767], и алгебраическая кольцевая модификация 2^2^n [например, 65536], с семантикой, которые были лучше в каждом случае. – supercat 22 April 2015 в 15:49
  • 3
    Было довольно распространено во многих системах с 16-разрядным int тип иметь отдельные объекты, которые были больше, чем 32K, но эффективно обрабатывающие объекты, больше, чем 64K, потребуют большего int тип. Проблема с unsigned int состоит в том, что, поскольку Вы вполне справедливо отмечаете, что это используется для выполнения двух непересекающихся ролей (числа по сравнению с алгебраическими кольцами). Я желаю, чтобы C добавил бы новые отдельные типы для натуральных чисел до 2^2^n-1 [например, 65535], натуральных чисел до 2^ (2^n-1)-1 [например, 32767], и алгебраическая кольцевая модификация 2^2^n [например, 65536], с семантикой, которые были лучше в каждом случае. – supercat 22 April 2015 в 15:49
  • 4
    Было довольно распространено во многих системах с 16-разрядным int тип иметь отдельные объекты, которые были больше, чем 32K, но эффективно обрабатывающие объекты, больше, чем 64K, потребуют большего int тип. Проблема с unsigned int состоит в том, что, поскольку Вы вполне справедливо отмечаете, что это используется для выполнения двух непересекающихся ролей (числа по сравнению с алгебраическими кольцами). Я желаю, чтобы C добавил бы новые отдельные типы для натуральных чисел до 2^2^n-1 [например, 65535], натуральных чисел до 2^ (2^n-1)-1 [например, 32767], и алгебраическая кольцевая модификация 2^2^n [например, 65536], с семантикой, которые были лучше в каждом случае. – supercat 22 April 2015 в 15:49
  • 5
    Было довольно распространено во многих системах с 16-разрядным int тип иметь отдельные объекты, которые были больше, чем 32K, но эффективно обрабатывающие объекты, больше, чем 64K, потребуют большего int тип. Проблема с unsigned int состоит в том, что, поскольку Вы вполне справедливо отмечаете, что это используется для выполнения двух непересекающихся ролей (числа по сравнению с алгебраическими кольцами). Я желаю, чтобы C добавил бы новые отдельные типы для натуральных чисел до 2^2^n-1 [например, 65535], натуральных чисел до 2^ (2^n-1)-1 [например, 32767], и алгебраическая кольцевая модификация 2^2^n [например, 65536], с семантикой, которые были лучше в каждом случае. – supercat 22 April 2015 в 15:49

Как уже говорили другие, временные метки могут представлять меньший диапазон времени (с 1970 по 2038 год). Однако временные метки измеряют количество секунд, прошедших с начала эпохи Unix (1970-01-01 00:00:00 UTC), что делает их независимыми от часового пояса, тогда как DATETIME сохраняет дату и время без часового пояса. Другими словами, временные метки однозначно ссылаются на конкретный момент времени, тогда как для точного момента времени, на который ссылается DATETIME, требуется часовой пояс (который не сохраняется в поле DATETIME). Чтобы понять, почему это может иметь значение, подумайте, что произойдет, если мы изменим наш часовой пояс.

Допустим, мы хотим сохранить дату и время 2010-03-27 12:00 UTC. Если мы сохраняем это и извлекаем его, используя временную метку или DATETIME, то, как правило, нет никакой разницы. Однако, если сервер теперь изменяется так, что местным часовым поясом является UTC + 01, тогда мы получим два разных результата, если извлечем дату и время.

Если бы мы установили поле в DATETIME, оно сообщило бы дату и время как 2010-03-27 12:00, несмотря на изменение часового пояса. Если бы мы установили в поле метку времени, дата была бы сообщена как 2010-03-27 11:00. Это не проблема ни с одним типом данных, это просто результат того, что они хранят немного другую информацию.

10
ответ дан Michael Williamson 28 March 2010 в 17:18
поделиться
  • 1
    Нет, границы упущения, проверяющие результаты в ошибки безопасности. Если Вы поняли его превратно в другом направлении, unsigned wouldn' t помогают Вам, Ваша функция счастливо записала бы в myArray[0xFFFFFFFF]. – dan04 16 July 2010 в 01:24
  • 2
    Нет, границы упущения, проверяющие результаты в ошибки безопасности. Если Вы поняли его превратно в другом направлении, unsigned wouldn' t помогают Вам, Ваша функция счастливо записала бы в myArray[0xFFFFFFFF]. – dan04 16 July 2010 в 01:24
  • 3
    Нет, границы упущения, проверяющие результаты в ошибки безопасности. Если Вы поняли его превратно в другом направлении, unsigned wouldn' t помогают Вам, Ваша функция счастливо записала бы в myArray[0xFFFFFFFF]. – dan04 16 July 2010 в 01:24
  • 4
    Нет, границы упущения, проверяющие результаты в ошибки безопасности. Если Вы поняли его превратно в другом направлении, unsigned wouldn' t помогают Вам, Ваша функция счастливо записала бы в myArray[0xFFFFFFFF]. – dan04 16 July 2010 в 01:24
  • 5
    Нет, границы упущения, проверяющие результаты в ошибки безопасности. Если Вы поняли его превратно в другом направлении, unsigned wouldn' t помогают Вам, Ваша функция счастливо записала бы в myArray[0xFFFFFFFF]. – dan04 16 July 2010 в 01:24
Другие вопросы по тегам:

Похожие вопросы: