Должен ли я использовать поле 'datetime' или 'timestamp'?

Вы порекомендовали бы использовать datetime или timestamp и почему (используя MySQL)?

Я работаю с PHP на стороне сервера.

2081
задан karlipoppins 03 янв. '09 в 19:14
источник поделиться

32 ответов

  • 1
  • 2

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

Если вы имели в виду, что хотите решить, использовать ли временную метку UNIX или собственное поле datetime MySQL, перейдите в собственный формат. Вы можете делать вычисления в MySQL таким образом ("SELECT DATE_ADD(my_datetime, INTERVAL 1 DAY)") и просто изменить формат значения на отметку времени UNIX ("SELECT UNIX_TIMESTAMP(my_datetime)") при запросе записи, если вы хотите работать с ней с помощью PHP.

1393
ответ дан blivet 03 янв. '09 в 19:26
источник поделиться

В MySQL 5 и выше значения TIMESTAMP преобразуются из текущего часового пояса в UTC для хранения и преобразуются обратно из UTC в текущий часовой пояс для извлечения. (Это происходит только для типа данных TIMESTAMP, а не для других типов, таких как DATETIME.)

По умолчанию текущий часовой пояс для каждого соединения - это время сервера. Часовой пояс может быть установлен для каждого соединения, как описано в Поддержка часовых поясов сервера MySQL.

753
ответ дан Nir 02 марта '09 в 14:49
источник поделиться

Я всегда использую поля DATETIME для чего-либо, кроме метаданных строк (дата создана или изменена).

Как упоминается в документации MySQL:

Тип DATETIME используется, когда вам нужны значения, содержащие информацию о дате и времени. MySQL извлекает и отображает значения DATETIME в формате "YYYY-MM-DD HH: MM: SS". Поддерживаемый диапазон: "1000-01-01 00:00:00" до "9999-12-31 23:59:59".

...

Тип данных TIMESTAMP имеет диапазон '1970-01-01 00:00:01' UTC to '2038-01-09 03:14:07' UTC. Он имеет разные свойства, в зависимости от версии MySQL и режима SQL, на котором работает сервер.

Вы, скорее всего, попадете в нижний предел для TIMESTAMPs в общем использовании - например. хранение даты рождения.

394
ответ дан scronide 04 янв. '09 в 7:26
источник поделиться

Ниже приведены примеры того, как тип даты TIMESTAMP изменил значения после изменения time-zone to 'america/new_york', где DATETIME не изменился.

mysql> show variables like '%time_zone%';
+------------------+---------------------+
| Variable_name    | Value               |
+------------------+---------------------+
| system_time_zone | India Standard Time |
| time_zone        | Asia/Calcutta       |
+------------------+---------------------+

mysql> create table datedemo(
    -> mydatetime datetime,
    -> mytimestamp timestamp
    -> );

mysql> insert into datedemo values ((now()),(now()));

mysql> select * from datedemo;
+---------------------+---------------------+
| mydatetime          | mytimestamp         |
+---------------------+---------------------+
| 2011-08-21 14:11:09 | 2011-08-21 14:11:09 |
+---------------------+---------------------+

mysql> set time_zone="america/new_york";

mysql> select * from datedemo;
+---------------------+---------------------+
| mydatetime          | mytimestamp         |
+---------------------+---------------------+
| 2011-08-21 14:11:09 | 2011-08-21 04:41:09 |
+---------------------+---------------------+

Я преобразовал свой ответ в статью, чтобы больше людей могли найти это полезное, MySQL: Datetime Versus Timestamp Data Types.

260
ответ дан mr_eclair 21 авг. '11 в 11:45
источник поделиться

Основное отличие состоит в том, что DATETIME является постоянным, а TIMESTAMP зависит от параметра time_zone.

Итак, это имеет значение только тогда, когда у вас есть — или может в будущем иметь; синхронизированных кластеров во временных зонах.

В более простых словах: Если у меня есть база данных в Австралии и дамп этой базы данных для синхронизации/заполнения базы данных в Америке, то TIMESTAMP будет обновляться, чтобы отображать реальное время события в новом часовой пояс, в то время как DATETIME будет по-прежнему отражать время события в часовой пояс.

Отличным примером DATETIME, используемого там, где TIMESTAMP должен был использоваться, является Facebook, где их серверы никогда не могут быть уверены в том, что произошло во время часовых поясов. Однажды у меня был разговор, в котором время говорило, что я отвечаю на сообщения, прежде чем сообщение действительно отправлено. (Это, конечно, также могло быть вызвано неправильным переводом часового пояса в программном обеспечении для обмена сообщениями, если время было отправлено, а не синхронизировано.)

156
ответ дан ekerner 14 янв. '10 в 17:26
источник поделиться

Я принимаю это решение на семантической основе.

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

Я использую поле datetime, когда дату/время можно установить и изменить произвольно. Например, когда пользователь может сохранить последующие изменения в назначении.

94
ответ дан unbeknown 03 янв. '09 в 20:11
источник поделиться

TIMESTAMP - 4 байта с 8 байтами для DATETIME.

http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html

Но, подобно тому, как Скронид сказал, что он имеет нижнюю границу 1970-го года. Он отлично подходит для всего, что может произойти в будущем, хотя;)

74
ответ дан Alex 04 янв. '09 в 12:00
источник поделиться
  • TIMESTAMP - это четыре байта против восьми байтов для DATETIME.

  • Временные метки также легче в базе данных и быстрее индексируются.

  • Тип DATETIME используется, когда вам нужны значения, содержащие информацию о дате и времени. MySQL извлекает и отображает значения DATETIME в формате "ГГГГ-ММ-ДД ЧЧ: ММ: СС". Поддерживаемый диапазон составляет 1000-01-01 00:00:00 'до 9999-12-31 23:59:59'.

Тип данных TIMESTAMP имеет диапазон от 1970-01-01 00:00:01 'UTC to 2038-01-09 03:14:07' UTC. Он имеет разные свойства, в зависимости от версии MySQL и режима SQL, на котором работает сервер.

  1. DATETIME постоянна, а TIMESTAMP - установкой time_zone.
66
ответ дан Vivek S 21 дек. '13 в 14:12
источник поделиться

Я рекомендую использовать ни поле DATETIME или TIMESTAMP. Если вы хотите представить определенный день в целом (например, день рождения), используйте тип DATE, но если вы более конкретны, вы, вероятно, заинтересованы в записи фактического момента, а не единицы время (день, неделя, месяц, год). Вместо использования DATETIME или TIMESTAMP используйте BIGINT и просто сохраните количество миллисекунд с эпохи (System.currentTimeMillis(), если вы используете Java). Это имеет несколько преимуществ:

  • Вы избегаете блокировки поставщика. Практически каждая база данных поддерживает целые числа относительно похожим образом. Предположим, вы хотите перейти в другую базу данных. Хотите ли вы беспокоиться о различиях между значениями MySQL DATETIME и о том, как Oracle их определяет? Даже среди разных версий MySQL, TIMESTAMPS имеют разный уровень точности. Совсем недавно MySQL поддерживал миллисекунды в метках времени.
  • Нет проблем с часовым поясом. Здесь были некоторые проницательные комментарии о том, что происходит с часовыми поясами с разными типами данных. Но разве это общее знание, и ваши коллеги все время будут учиться этому? С другой стороны, довольно сложно перепутать BigINT с java.util.Date. Использование BIGINT приводит к множеству проблем с часовыми поясами, которые падают на обочину.
  • Не беспокойтесь о диапазонах или точности. Вам не нужно беспокоиться о том, что будет сокращено будущими диапазонами дат (TIMEZONE только до 2038).
  • Интеграция сторонних инструментов. Используя целое число, оно тривиально для сторонних инструментов (например, EclipseLink) для взаимодействия с базой данных. Не каждый сторонний инструмент будет иметь такое же представление о "datetime", как это делает MySQL. Хотите попытаться выяснить в Hibernate, следует ли использовать объект java.sql.TimeStamp или java.util.Date, если вы используете эти настраиваемые типы данных? Использование базовых типов данных используется с сторонними инструментами тривиально.

Эта проблема тесно связана с тем, как вы должны хранить денежную ценность (то есть 1,99 доллара США) в базе данных. Должны ли вы использовать десятичный код или тип денег в базе данных или, что хуже всего, Double? Все 3 из этих вариантов ужасны, по многим причинам, перечисленным выше. Решение заключается в том, чтобы хранить стоимость денег в центах с помощью BIGINT, а затем конвертировать центы в доллары, когда вы показываете значение для пользователя. Задача базы данных состоит в том, чтобы хранить данные, а НЕ для того, чтобы проинформировать эти данные. Все эти причудливые типы данных, которые вы видите в базах данных (особенно Oracle), мало добавляют и запускают вас по пути к блокировке поставщика.

52
ответ дан user64141 12 июня '14 в 2:02
источник поделиться

Зависит от приложения, действительно.

Рассмотрите возможность установки метки времени пользователем на сервер в Нью-Йорке для назначения в Сангхай. Теперь, когда пользователь подключается в Сангхай, он обращается к той же самой отметке времени назначения с зеркального сервера в Токио. Он увидит назначение в Токийское время, компенсированное первоначальным нью-йоркским временем.

Таким образом, для значений, представляющих пользовательское время, например, назначение или расписание, datetime лучше. Он позволяет пользователю контролировать точную дату и время, независимо от настроек сервера. Установленное время - это установленное время, не зависящее от часового пояса сервера, пользовательского часового пояса или изменения в способе расчета летнего времени (да, это действительно так).

С другой стороны, для значений, представляющих системное время, такие как платежные операции, изменения таблицы или ведение журнала, всегда используйте временные метки. На систему не повлияет перемещение сервера в другой часовой пояс или при сравнении между серверами в разных часовых поясах.

Временные метки также легче в базе данных и быстрее индексируются.

32
ответ дан ianaré 27 окт. '10 в 0:07
источник поделиться
Поле

A timestamp является частным случаем поля datetime. Вы можете создать столбцы timestamp, чтобы иметь специальные свойства; он может быть настроен на обновление самого себя при создании и/или обновлении.

В терминах "больших" баз данных timestamp имеет несколько триггеров специального случая на нем.

То, что правильно, полностью зависит от того, что вы хотите сделать.

22
ответ дан Jeff Warnica 03 янв. '09 в 19:21
источник поделиться

TIMESTAMP всегда находится в UTC (то есть, прошедшие секунды с 1970-01-01, в UTC), и ваш MySQL-сервер автоматически конвертирует его в дату/время для часовой пояс сервера. В долгосрочной перспективе TIMESTAMP - это путь, потому что вы знаете, что ваши временные данные всегда будут в UTC. Например, вы не будете вставлять свои даты, если вы перейдете на другой сервер или измените настройки часового пояса на своем сервере.

20
ответ дан Sobes 26 авг. '10 в 2:21
источник поделиться

Стоит отметить, что в MySQL вы можете использовать что-то по строкам ниже при создании столбцов таблицы:

on update CURRENT_TIMESTAMP

Это будет обновлять время в каждом экземпляре, который вы модифицируете строку, и иногда очень полезно для сохранения последней информации редактирования. Это работает только с меткой времени, но не с datetime.

17
ответ дан leejmurphy 07 янв. '12 в 2:04
источник поделиться

2016 +: я советую установить часовой пояс Mysql для UTC и использовать DATETIME:

Любая недавняя инфраструктура front-end (Angular 1/2, response, Vue,...) может легко и автоматически конвертировать ваше время и время UTC в локальное время.

Дополнительно:

(Если вы, скорее всего, не измените часовой пояс своих серверов)


Пример с AngularJs

// back-end: format for angular within the sql query
SELECT DATE_FORMAT(my_datetime, "%Y-%m-%dT%TZ")...

// font-end Output the localised time
{{item.my_datetime | date :'medium' }}

Доступен весь локализованный формат времени: https://docs.angularjs.org/api/ng/filter/date

17
ответ дан Sebastien Horin 18 февр. '16 в 1:36
источник поделиться

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

Чтобы получить текущую временную метку Unix в PHP, просто time();
и в MySQL do SELECT UNIX_TIMESTAMP();.

15
ответ дан Mark Davidson 03 янв. '09 в 19:18
источник поделиться

Я всегда использую временную метку Unix, просто для поддержания здравомыслия при работе с большим количеством информации о времени и времени, особенно при выполнении корректировок для часовых поясов, добавлении/вычитании дат и т.п. При сравнении временных меток это исключает усложняющие факторы часового пояса и позволяет вам сэкономить ресурсы в обработке на стороне сервера (будь то код приложения или запросы к базе данных) в том, что вы используете арифметику легкого веса, а не более тяжелую дату-время добавить/вычесть функции.

Еще одна вещь, которую стоит рассмотреть:

Если вы создаете приложение, вы никогда не знаете, как ваши данные могут быть использованы по линии. Если вам придется, скажем, сравнить кучу записей в вашем наборе данных, скажем, с кучей элементов из стороннего API, и, скажем, поставить их в хронологическом порядке, вы будете счастливы иметь Временные метки Unix для ваших строк. Даже если вы решите использовать временные метки MySQL, сохраните временную метку Unix как страховку.

11
ответ дан Oliver Holmberg 05 янв. '12 в 5:50
источник поделиться

Еще одно отличие между Timestamp и Datetime в Timestamp, вы не можете использовать значение по умолчанию NULL.

10
ответ дан ecleel 19 янв. '14 в 14:06
источник поделиться

Тип данных временной метки хранит дату и время, но в формате UTC, а не в текущем формате часового пояса, как это делает datetime. И когда вы извлекаете данные, timestamp снова преобразует это в текущее время часовой пояс.

Предположим, вы находитесь в США и получаете данные с сервера, который имеет часовой пояс США. Затем вы получите дату и время в соответствии с часовым поясом США. Столбец данных временной метки всегда обновляется автоматически, когда его строка обновляется. Поэтому может быть полезно отслеживать, когда последняя строка была обновлена ​​в последний раз.

Для более подробной информации вы можете прочитать сообщение в блоге Timestamp Vs Datetime.

10
ответ дан Arvind 20 дек. '12 в 11:48
источник поделиться

Из моего опыта, если вы хотите, чтобы поле даты, в которое вставка происходит только один раз, и вы не хотите иметь какое-либо обновление или какое-либо другое действие в этом конкретном поле, переходите к дате времени.

Например, рассмотрим таблицу user с полем РЕГИСТРАЦИЯ ДАТА. В этой таблице user, если вы хотите узнать последнее время входа в систему определенного пользователя, перейдите в поле типа timestamp, чтобы поле было обновлено.

Если вы создаете таблицу из phpMyAdmin, значение по умолчанию обновит поле timestamp, когда строка обновление происходит. Если ваша временная метка не обновляется с обновлением строки, вы можете использовать следующий запрос, чтобы сделать поле timestamp автоматически обновляться.

ALTER TABLE your_table
      MODIFY COLUMN ts_activity TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP;
10
ответ дан Kannan Prasad 06 февр. '12 в 6:34
источник поделиться

Остерегайтесь изменения временной метки, когда вы выполняете инструкцию UPDATE в таблице. Если у вас есть таблица со столбцами "Имя" (varchar), "Age" (int) и "Date_Added" (временная метка), и вы запускаете следующий оператор DML

UPDATE table
SET age = 30

то каждое значение в столбце "Date_Added" будет изменено на текущую временную метку.

10
ответ дан Lloyd Banks 04 окт. '13 в 9:00
источник поделиться

Основное отличие:

  • a INDEX на отметке времени - работает
  • a INDEX в Datetime - Не работает

посмотрите на это сообщение чтобы увидеть проблемы с индексированием Datetime

9
ответ дан Charles Faiga 07 марта '14 в 15:09
источник поделиться

Сравнение между DATETIME, TIMESTAMP и DATE

введите описание изображения здесь

Что это [.fraction]?

  • Значение DATETIME или TIMESTAMP может включать трейлинг-дробное секунд в минуту до точностью до микросекунд (6 цифр). В в частности, любая дробная часть в значении, вставленном в DATETIME или столбцы TIMESTAMP сохраняются, а не отбрасываются. Это, конечно, необязательно.

Источники:

9
ответ дан jdc91 11 авг. '17 в 12:53
источник поделиться

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

Он может отслеживать различные часовые пояса, поэтому, если вам нужно отобразить относительное время, например, время UTC - это то, что вы хотели бы.

8
ответ дан Marc DiMillo 01 нояб. '11 в 22:42
источник поделиться

Ссылка, взятая из этой статьи:

Основные отличия:

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

TIMESTAMP также зависит от настройки, связанной с TIME ZONE. DATETIME постоянна.

TIMESTAMP внутренне преобразует текущий часовой пояс в UTC для хранения, а во время поиска преобразуется обратно в текущий часовой пояс. DATETIME не может этого сделать.

Поддерживаемый диапазон TIMESTAMP: '1970-01-01 00:00:01' UTC to '2038-01-19 03:14:07' UTC Поддерживаемый диапазон DATETIME: '1000-01-01 00:00:00' до '9999-12-31 23:59:59'

7
ответ дан Anvesh 07 февр. '16 в 15:49
источник поделиться

Я предпочитаю использовать временную метку, чтобы сохранить все в одном распространенном необработанном формате и форматировать данные в PHP-коде или в вашем SQL-запросе. Бывают случаи, когда вам удобно в вашем коде хранить все в считанные секунды.

6
ответ дан Hans 04 янв. '09 в 10:49
источник поделиться

Мне нравится отметка времени Unix, потому что вы можете конвертировать в числа и просто беспокоиться о номере. Кроме того, вы добавляете/вычитаете и получаете длительность и т.д. Затем преобразуйте результат в Date в любом формате. Этот код узнает, сколько времени в минутах прошло между меткой времени от документа и текущим временем.

$date  = $item['pubdate']; (etc ...)
$unix_now = time();
$result = strtotime($date, $unix_now);
$unix_diff_min = (($unix_now  - $result) / 60);
$min = round($unix_diff_min);
5
ответ дан user723220 28 апр. '11 в 20:34
источник поделиться

В моем случае я устанавливаю UTC как часовой пояс для всего: системы, сервера базы данных и т.д. каждый раз, когда я могу. Если моему клиенту требуется другой часовой пояс, я настраиваю его в приложении.

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

В качестве плюса, в случае миграции базы данных в систему с другим часовым поясом, я бы чувствовал себя более уверенно, используя временные метки. Нельзя говорить о возможных проблемах при расчете различий между двумя моментами с изменением времени ожидания между ними и необходимостью точности 1 час или менее.

Итак, резюмируя, я ценю эти преимущества метки времени:

  • готовые к использованию в международных (многочасовых) приложениях
  • легкая миграция между часовыми поясами
  • довольно легко рассчитать различия (просто вычтите обе временные метки)
  • Не беспокойтесь о датах в/из летнего периода.

По всем этим причинам я выбираю поля UTC и timestamp, где это возможно. И я избегаю головных болей;)

4
ответ дан rogerpro 24 февр. '17 в 21:19
источник поделиться

A TIMESTAMP требуется 4 байта, тогда как для DATETIME требуется 8 байт.

4
ответ дан Mwangi Thiga 23 июня '16 в 17:12
источник поделиться

Пока не указано, что DEFAULT CURRENT_TIMESTAMP работает только с полями Timestamp, но не с типом DateTime.

Это становится актуальным для таблиц MS Access, которые могут использовать только DateTime, но не Timestamp.

3
ответ дан Eliptical view 03 нояб. '16 в 22:27
источник поделиться

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

2
ответ дан Mahdi Jazini 27 окт. '16 в 10:59
источник поделиться
  • 1
  • 2

Другие вопросы по меткам