Чи варто використовувати тип даних дати або часових позначок у MySQL?

Чи рекомендуєте ви використовувати дату або поле часової позначки , і чому (використовуючи MySQL)?

Я працюю з PHP на стороні сервера.

Часові позначки в MySQL зазвичай використовуються для відстеження змін у записах і часто оновлюються щоразу, коли запис змінюється. Якщо ви хочете зберегти певне значення, слід скористатися полем дати.

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

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

За замовчуванням поточний часовий пояс для кожного з'єднання - це час сервера. Часовий пояс можна встановити на основі підключення, як описано в службі підтримки часових поясів MySQL Server .

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

Як зазначено в документації на MySQL:

Тип DATETIME використовується, коли потрібні значення, що містять інформацію про дату та час. MySQL отримує та відображає значення DATETIME у форматі "РРРР-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 до '2038-01-09 03:14:07 UTC. Він має різні властивості, залежно від версії MySQL та режиму SQL, на якому працює сервер.

Ви, швидше за все, підпадаєте під нижню межу для TIMESTAMP в загальному користуванні - наприклад, зберігання дати народження.

Наведені нижче приклади показують, як 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 Типи даних .

Основна відмінність полягає в тому, що DATETIME є постійним, тоді як TIMESTAMP впливає на time_zoneналаштування.

Отже, це важливо лише тоді, коли у вас є - або, можливо, у майбутньому - синхронізовані кластери через часові пояси.

Простішими словами: Якщо я маю базу даних в Австралії і займуся дапом цієї бази даних для синхронізації / заповнення бази даних в Америці, то TIMESTAMP буде оновлений, щоб відобразити реальний час події в новому часовому поясі, тоді як DATETIME буде як і раніше відображають час події у часовому поясі au .

Чудовий приклад використання DATETIME там, де слід було використовувати TIMESTAMP, - це Facebook, де їх сервери ніколи не знають, який час відбувся в часових поясах. Одного разу в мене була розмова, в якій час говорив, що я відповідаю на повідомлення, перш ніж повідомлення було фактично надіслане. (Звичайно, це також може бути спричинене поганим перекладом часового поясу в програмному забезпеченні для обміну повідомленнями, якби час був розміщений, а не синхронізований.)

Я приймаю це рішення на смисловій основі.

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

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

Я не рекомендую використовувати ні 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) тривіально взаємодіяти з базою даних. Не кожен сторонній інструмент матиме те саме розуміння "дати", як і MySQL. Хочете спробувати з’ясувати, чи слід використовувати об’єкт java.sql.TimeStamp або java.util.Date, якщо ви використовуєте ці власні типи даних? Використання базових типів даних використовує сторонні інструменти тривіально.

Це питання тісно пов’язане з тим, як слід зберігати цінність грошей (тобто 1,99 долара) у базі даних. Чи варто використовувати десятковий або тип грошей у базі даних чи найгірше подвійний? Всі 3 з цих варіантів жахливі з багатьох тих самих причин, які були перераховані вище. Рішення полягає в тому, щоб зберігати вартість грошей у копіях за допомогою BIGINT, а потім конвертувати центи в долари, коли ви показуєте цінність для користувача. Завдання бази даних - зберігати дані, а НЕ вводити ці дані в інтерпретацію. Усі ці фантазійні типи даних, які ви бачите в базах даних (особливо Oracle), додають мало, і починають вас в дорогу до блокування постачальників.

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

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

Але, як і скронід, він сказав, що у нього є нижня межа 1970 року. Це чудово для всього, що може статися в майбутньому;)

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

2. Тимчасові позначки також легші на базі даних та індексуються швидше.

3. Тип DATETIME використовується, коли потрібні значення, що містять інформацію про дату та час. MySQL отримує та відображає значення DATETIME у форматі "РРРР-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 до '2038-01-09 03:14:07' UTC. Він має різні властивості, залежно від версії MySQL та режиму SQL, на якому працює сервер.

4. DATETIME є постійним, тоді як TIMESTAMP впливає на налаштування часової зони.

Насправді залежить від застосування.

Подумайте про встановлення часової позначки користувачем на сервері в Нью-Йорку для зустрічі в Сангхаї. Тепер, коли користувач підключається до Сангхая, він отримує таку ж мітку часу призначення з дзеркального сервера в Токіо. Він побачить зустріч у токійський час, компенсований від початкового нью-йоркського часу.

Тож для значень, які представляють час користувача, як зустріч або графік, час дати краще. Це дозволяє користувачеві контролювати потрібну дату та час, незалежно від налаштувань сервера. Встановлений час - це встановлений час, на який не впливає часовий пояс сервера, часовий пояс користувача або зміни способу обчислення літнього часу (так, він змінюється).

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

Тимчасові позначки також легші на базі даних та індексуються швидше.

2016 + : радимо встановити часовий пояс Mysql на UTC та використовувати DATETIME:

Будь-який останній фронтальний фреймворк (кутовий 1/2, реагувати, Vue, ...) може легко і автоматично перетворити ваш дату UTC в місцевий час

Додатково:

• DATETIME тепер може бути автоматично встановлено на поточне значення часу Як встановити значення за замовчуванням для стовпця MySQL Datetime?
• Всупереч тому, що можна подумати, DATETIME швидше, ніж TIMESTAMP, http://gpshumano.blogs.dri.pt/2009/07/06/mysql-datetime-vs-timestamp-vs-int-performance-and-benchmarking-with -мійсам /
• TIMESTAMP все ще обмежений 1970-2038 роками

(Якщо ви, швидше за все, не зміните часовий пояс ваших серверів)

Приклад з 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

timestampПоле є окремим випадком datetimeполя. Ви можете створювати timestampстовпці, щоб мати спеціальні властивості; його можна встановити для оновлення як при створенні, так і / або оновленні.

У "більших" умовах бази даних, timestampє кілька тригерів спеціального випадку.

Те, що є правильним, повністю залежить від того, що ви хочете зробити.

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

Примітка: часовий пояс підключення за замовчуванням - це часовий пояс сервера, але це можна (слід) змінити за сеанс (див. SET time_zone = ...).

Порівняння DATETIME, TIMESTAMP та DATE

Що це [.фракція]?

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

Джерела:

• Посилання на дані про дату / час MySQL
• Посилання на вимоги до зберігання MySQL

Варто зауважити, що в MySQL ви можете використовувати щось відповідно до наведених нижче під час створення стовпців таблиці:

on update CURRENT_TIMESTAMP

Це оновлює час у кожному випадку, коли ви змінюєте рядок, а іноді дуже корисно для збереження інформації про останнє редагування. Це працює лише з позначкою часу, але не з датою.

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

Щоб отримати поточну мітку часу Unix в PHP, просто зробіть time();
і в MySQL зробіть SELECT UNIX_TIMESTAMP();.

З мого досвіду, якщо ви хочете поле дати, в яке вставлення відбувається лише один раз, і ви не хочете жодних оновлень чи будь-яких інших дій у цьому конкретному полі, перейдіть із часом дати .

Наприклад, розгляньте userтаблицю з полем ДАТА РЕЄСТРАЦІЇ . У цій userтаблиці, якщо ви хочете дізнатися про останній час входу конкретного користувача, перейдіть із полем часової позначки щоб поле оновлювалося.

Якщо ви створюєте таблицю з phpMyAdmin, налаштування за замовчуванням оновить поле часової позначки, коли відбудеться оновлення рядків. Якщо подана вами часова марка не оновлюється оновленням рядків, ви можете скористатись наступним запитом, щоб зробити поле часу мітки автоматично оновленим.

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

Тип даних часових позначок зберігає дату та час, але у форматі UTC, а не у поточному форматі часового поясу, як це відбувається. А коли ви отримуєте дані, часова марка знову перетворює це в поточний час часового поясу.

Тож припустимо, що ви перебуваєте в США та отримуєте дані з сервера, який має часовий пояс США. Тоді ви отримаєте дату та час відповідно до часового поясу в США. Стовпчик даних про часові позначки завжди оновлюється автоматично, коли його рядок оновлюється. Тож може бути корисно відстежувати, коли певний рядок було оновлено востаннє.

Більш детальну інформацію можна прочитати в блозі Timestamp Vs Datetime .

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

Ще одна річ, яку варто врахувати:

Якщо ви створюєте додаток, ви ніколи не знаєте, як ваші дані можуть бути використані внизу. Якщо вам доведеться, скажімо, порівняти купу записів у вашому наборі даних, скажімо, з купою елементів із стороннього API та скажіть, поставте їх у хронологічному порядку, ви будете раді Часові позначки Unix для ваших рядків. Навіть якщо ви вирішили використовувати часові позначки MySQL, зберігайте часові позначки Unix як страховку.

У моєму випадку я встановлюю UTC як часовий пояс для всього: системи, сервера баз даних і т. Д. Кожного разу, коли можу. Якщо мій клієнт вимагає іншого часового поясу, я налаштовую його в додатку.

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

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

Отже, підсумовуючи, я ціную ці переваги часової позначки:

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

З усіх цих причин я вибираю поля UTC та часові позначки, де це можливо. І я уникаю головних болів;)

Остерігайтеся зміни часової позначки, коли ви робите оператор UPDATE на таблиці. Якщо у вас є таблиця зі стовпцями "Ім'я" (varchar), "Age" (int) та "Date_Added" (мітка часу), і ви запускаєте наступний оператор DML

UPDATE table
SET age = 30

то кожне значення у стовпці "Дата_Додано" буде змінено на поточну часову позначку.

Довідка, взята з цієї статті:

Основні відмінності:

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

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

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

TIMESTAMP підтримується діапазон: '1970-01-01 00:00:01' UTC до '2038-01-19 03:14:07' UTC DATETIME підтримується діапазон: '1000-01-01 00:00:00' до '9999 -12-31 23:59:59 ′

+---------------------------------------------------------------------------------------+--------------------------------------------------------------------------+
|                                       TIMESTAMP                                       |                                 DATETIME                                 |
+---------------------------------------------------------------------------------------+--------------------------------------------------------------------------+
| TIMESTAMP requires 4 bytes.                                                           | DATETIME requires 8 bytes.                                               |
| Timestamp is the number of seconds that have elapsed since January 1, 1970 00:00 UTC. | DATETIME is a text displays 'YYYY-MM-DD HH:MM:SS' format.                |
| TIMESTAMP supported range: ‘1970-01-01 00:00:01′ UTC to ‘2038-01-19 03:14:07′ UTC.    | DATETIME supported range: ‘1000-01-01 00:00:00′ to ‘9999-12-31 23:59:59′ |
| TIMESTAMP during retrieval converted back to the current time zone.                   | DATETIME can not do this.                                                |
| TIMESTAMP is used mostly for metadata i.e. row created/modified and audit purpose.    | DATETIME is used mostly for user-data.                                   |
+---------------------------------------------------------------------------------------+--------------------------------------------------------------------------+

Ще одна різниця між Timestamp і Datetime полягає в Timestamp, за замовчуванням ви не можете встановити значення NULL.

Я виявив неперевершену корисність у можливості TIMESTAMP автоматично оновлюватись на основі поточного часу без використання зайвих тригерів. Це тільки я, хоча TIMESTAMP - це UTC, як це було сказано.

Він може відслідковувати різні часові пояси, тому, якщо вам потрібно відобразити відносний час, наприклад, час UTC - це саме те, що ви хотіли б.

Основна різниця

• INDEX на Timestamp - працює
• INDEX на Datetime - не працює

перегляньте цю публікацію, щоб побачити проблеми з індексуванням дати

Я перестав використовуватись datetimeу своїх додатках після багатьох проблем та помилок, пов’язаних із часовими поясами. Використання IMHO timestampкраще, ніж datetimeу більшості випадків .

Коли ви запитуєте, який час? і відповідь приходить як щось на кшталт "2019-02-05 21:18:30", тобто не завершена, не визначена відповідь, оскільки в ній часовій зоні відсутня інша частина? Вашингтон? Москва? Пекін?

Використання дат без часового поясу означає, що ваша програма має лише один часовий пояс, проте часові позначки дають вам переваги datetimeплюс гнучкість показу однакового точного моменту часу в різних часових поясах.

Ось декілька випадків, які змусять вас пошкодувати про використання datetimeта побажання зберегти свої дані у часових позначках.

1. Для комфорту своїх клієнтів ви хочете показувати їм час на основі їх бажаних часових поясів, не змушуючи їх робити математику та перетворювати час на їхній змістовний часовий пояс. все, що вам потрібно, це змінити часовий пояс, і весь код вашої програми буде однаковим. (Насправді ви завжди повинні визначати часовий пояс на початку програми або обробляти запит у випадку PHP-програм)

   SET time_zone = '+2:00';

2. ви змінили країну, в якій ви перебуваєте, і продовжуєте роботу над збереженням даних, переглядаючи їх в іншому часовому поясі (без зміни фактичних даних).

3. ви приймаєте дані від різних клієнтів у всьому світі, кожен з них вставляє час у свій часовий пояс.

Коротко

datetime = програма підтримує 1 часовий пояс (і для вставки, і для вибору)

timestamp = програма підтримує будь-який часовий пояс (і для вставки, і для вибору)

Ця відповідь призначена лише для того, щоб виділити деяку увагу на гнучкість та простоту часових позначок, коли мова йде про часові пояси, вона не охоплює будь-яких інших відмінностей, таких як розмір стовпця або діапазон чи частка .

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

А TIMESTAMPпотрібно 4 байти, тоді як а DATETIME8 - байт.

Мені подобається часова мітка 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);