timestamp mysql пример




Должен ли я использовать тип данных datetime или timestamp в MySQL? (20)

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

Любая недавняя инфраструктура интерфейса (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

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

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


  1. TIMESTAMP - это четыре байта против восьми байтов для DATETIME.

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

  3. Тип 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, на котором работает сервер.

  1. DATETIME постоянна, а TIMESTAMP - установкой time_zone.

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


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

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


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

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


Другое различие между Timestamp и Datetime в Timestamp вы не можете использовать значение по умолчанию NULL.


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

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

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

ALTER TABLE your_table
      MODIFY COLUMN ts_activity TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP;


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

UPDATE table
SET age = 30

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


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

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

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


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

on update CURRENT_TIMESTAMP

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


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

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

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


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

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

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


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

Как dev.mysql.com/doc/refman/5.1/en/datetime.html в документации 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 в общем использовании - например, для хранения даты рождения.


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

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

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


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

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

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


A TIMESTAMPтребует 4 байта, тогда как a DATETIMEтребует 8 байтов.


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


Мне нравится временная метка 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);

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





sqldatatypes