Вероятно, многие программисты хотят задать этот вопрос. это Каковы преимущества каждого из этих форматов времени MySQL. и какой из них вы предпочитаете использовать в своих приложениях.
Для меня я использую временную метку Unix, потому что, возможно, мне легко конвертировать и записывать записи с ней, а также потому, что я никогда не пробовал DATETIME. но в любом случае я готов изменить свое мнение, если кто-нибудь скажет мне, что я неправ.
благодаря
Временная метка (как PHP, так и MySQL) хранится с использованием 32 битов (т. Е. 4 байта) целых чисел; что означает, что они ограничены диапазоном дат, который идет с 1970 по 2038 год.
DATETIME не имеют этого ограничения, но сохраняются с использованием большего количества байтов (8 байтов, если я не ошибаюсь)
После этого между хранением временных меток, как видно из PHP, или временными метками, как видно из MySQL:
Более подробную информацию о DATETIME данных MySQL TIMESTAMP и DATETIME см . В разделе 10.3.1. Типы DATETIME, DATE и TIMESTAMP
Как отмечали другие, временные метки могут представлять меньший диапазон дат (с 1970 по 2038 год). Тем не менее, временные метки измеряют количество секунд со времен Unix Epoch (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. Это не проблема ни с одним типом данных – это просто результат того, что они хранят немного другую информацию.
Это действительно зависит. Я приведу вам два примера, где один из них можно преодолеть:
Временная метка лучше, чем DATETIME, когда вы хотите сохранить сеанс пользователей в базе данных, а время создания сеанса (в формате Timestamp) используется для быстрого поиска строк (с индексом).
Например, таблица может выглядеть так:
[session_create_time AS Timestamp][IP_address AS 32bit Int][etc...]
Наличие индекса в первых двух столбцах может действительно ускорить ваши запросы. Если у вас есть тип значения DATETIME для поля session_create_time , это может занять гораздо больше времени. Учтите, что запросы сеанса выполняются каждый раз, когда пользователь запрашивает страницу , поэтому эффективность имеет решающее значение.
DATETIME лучше, чем Timestamp, когда вы хотите сохранить дату рождения пользователя или некоторые исторические события, требующие гибкого временного диапазона.
Если оцифровывать записи до 1 января 1970 года, мне нравится эпоха UNIX. Его просто вопрос предпочтения, целые беззнаковые числа проще обрабатывать при использовании нескольких языков.
Просто имейте в виду, что эпоха начинается с 1 января 1970 года. До этого многие компании работали в течение десятилетий, если не дольше.