Question Dois-je utiliser le type de données datetime ou timestamp dans MySQL?


Recommanderiez-vous l'utilisation d'un datetime ou un horodatage champ, et pourquoi (en utilisant MySQL)?

Je travaille avec PHP sur le serveur.


2299
2018-01-03 16:14


origine


Réponses:


Les horodatages dans MySQL sont généralement utilisés pour suivre les modifications apportées aux enregistrements et sont souvent mis à jour chaque fois que l'enregistrement est modifié. Si vous souhaitez stocker une valeur spécifique, vous devez utiliser un champ datetime.

Si vous voulez dire que vous voulez choisir entre un horodatage UNIX ou un champ datetime natif MySQL, utilisez le format natif. Vous pouvez faire des calculs dans MySQL de cette façon ("SELECT DATE_ADD(my_datetime, INTERVAL 1 DAY)") et il est simple de changer le format de la valeur en un timestamp UNIX ("SELECT UNIX_TIMESTAMP(my_datetime)") lorsque vous interrogez l'enregistrement si vous voulez opérer avec PHP.


1555
2018-01-03 16:26



En MySQL 5 et plus, TIMESTAMP les valeurs sont converties à partir du fuseau horaire actuel en UTC pour le stockage, et reconverties de UTC vers le fuseau horaire actuel pour la récupération. (Cela se produit uniquement pour le type de données TIMESTAMP, et ne pas pour d'autres types tels que DATETIME.)

Par défaut, le fuseau horaire actuel pour chaque connexion correspond à l'heure du serveur. Le fuseau horaire peut être défini par connexion, comme décrit dans Prise en charge du fuseau horaire du serveur MySQL.


814
2018-03-02 11:49



J'utilise toujours les champs DATETIME pour tout autre élément que les métadonnées de ligne (date de création ou de modification).

Comme mentionné dans la documentation MySQL:

Le type DATETIME est utilisé lorsque vous avez besoin de valeurs contenant à la fois des informations de date et d'heure. MySQL récupère et affiche les valeurs DATETIME au format 'AAAA-MM-JJ HH: MM: SS'. La plage prise en charge est '1000-01-01 00:00:00' à '9999-12-31 23:59:59'.

...

Le type de données TIMESTAMP a une plage de '1970-01-01 00:00:01' UTC à '2038-01-09 03:14:07' UTC. Il a des propriétés variables, en fonction de la version de MySQL et du mode SQL utilisé par le serveur.

Vous êtes tout à fait susceptible d'atteindre la limite inférieure des TIMESTAMP en général - par ex. stocker la date de naissance.


430
2018-01-04 04:26



Les exemples ci-dessous montrent comment TIMESTAMP type de date a changé les valeurs après avoir changé le time-zone to 'america/new_york' où DATETIMEest inchangé.

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 |
+---------------------+---------------------+

J'ai converti ma réponse en article afin que plus de gens puissent trouver cela utile, MySQL: Datetime Versus types de données d'horodatage.


284
2017-08-21 08:45



La principale différence est que DATETIME est constant tandis que TIMESTAMP est affecté par le time_zone réglage.

Ainsi, cela n'a d'importance que lorsque vous avez synchronisé des clusters entre différents fuseaux horaires, ou que vous en aurez peut-être besoin à l'avenir.

En termes plus simples: Si j'ai une base de données en Australie, et que j'envoie une sauvegarde de cette base de données pour synchroniser / peupler une base de données en Amérique, TIMESTAMP se mettrait à jour pour refléter l'heure réelle de l'événement dans le nouveau fuseau horaire, alors que DATETIME de l'événement dans le fuseau horaire au.

Un bon exemple de DATETIME utilisé où TIMESTAMP aurait dû être utilisé est sur Facebook, où ses serveurs ne sont jamais vraiment sûrs de l'heure à laquelle les choses se passent dans les fuseaux horaires. Une fois, j'avais une conversation dans laquelle l'heure disait que je répondais aux messages avant que le message ne soit envoyé. (Ceci, bien sûr, pourrait aussi avoir été causé par une mauvaise traduction de fuseau horaire dans le logiciel de messagerie si les heures étaient affichées plutôt que synchronisées.)


169
2018-01-14 14:26



Je prends cette décision sur une base sémantique.

J'utilise un horodatage lorsque j'ai besoin d'enregistrer un point (plus ou moins) fixe dans le temps. Par exemple, lorsqu'un enregistrement a été inséré dans la base de données ou lorsqu'une action de l'utilisateur a eu lieu.

J'utilise un champ datetime lorsque la date / heure peut être définie et modifiée arbitrairement. Par exemple, lorsqu'un utilisateur peut enregistrer plus tard des rendez-vous.


109
2018-01-03 17:11



TIMESTAMP est 4 octets Vs 8 octets pour DATETIME.

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

Mais comme le scronide a dit qu'il a une limite inférieure de l'année 1970. C'est génial pour tout ce qui pourrait arriver dans le futur;)


86
2018-01-04 09:00



  1. TIMESTAMP est quatre octets vs huit octets pour DATETIME.

  2. Les horodatages sont également plus légers sur la base de données et indexés plus rapidement.

  3. Le type DATETIME est utilisé lorsque vous avez besoin de valeurs contenant à la fois des informations de date et d'heure. MySQL récupère et affiche les valeurs DATETIME au format 'AAAA-MM-JJ HH: MM: SS'. La plage prise en charge est '1000-01-01 00:00:00' à '9999-12-31 23:59:59'.

Le type de données TIMESTAMP a une plage de '1970-01-01 00:00:01' UTC à '2038-01-09 03:14:07' UTC. Il a des propriétés variables, en fonction de la version de MySQL et du mode SQL utilisé par le serveur.

  1. DATETIME est constant pendant que TIMESTAMP est effectué par le paramètre time_zone.

80
2017-12-21 11:12



Je recommande d'utiliser ni un champ DATETIME ou TIMESTAMP. Si vous souhaitez représenter un jour spécifique dans son ensemble (comme un anniversaire), utilisez un type DATE, mais si vous êtes plus précis que cela, vous êtes probablement intéressé par l'enregistrement d'un moment réel par opposition à une unité de heure (jour, semaine, mois, année). Au lieu d'utiliser un DATETIME ou TIMESTAMP, utilisez un BIGINT, et stockez simplement le nombre de millisecondes depuis l'époque (System.currentTimeMillis () si vous utilisez Java). Cela a plusieurs avantages:

  1. Vous évitez le verrouillage du fournisseur. Presque toutes les bases de données prennent en charge les entiers de manière relativement similaire. Supposons que vous souhaitiez passer à une autre base de données. Voulez-vous vous soucier des différences entre les valeurs DATETIME de MySQL et comment Oracle les définit? Même parmi les différentes versions de MySQL, TIMESTAMPS a un niveau de précision différent. Ce n'est que récemment que MySQL a pris en charge les millisecondes dans les horodatages.
  2. Aucun problème de fuseau horaire. Il y a eu quelques commentaires perspicaces ici sur ce qui se passe avec les fuseaux horaires avec les différents types de données. Mais est-ce une connaissance commune, et vos collègues prendront-ils tous le temps de l'apprendre? D'un autre côté, il est plutôt difficile de changer un BigINT en java.util.Date. L'utilisation d'un BIGINT cause beaucoup de problèmes avec les fuseaux horaires.
  3. Pas de soucis de gammes ou de précision. Vous n'avez pas à vous soucier de ce qui est coupé par les plages de dates futures (TIMESTAMP ne va qu'en 2038).
  4. Intégration d'outils tiers. En utilisant un entier, il est trivial pour les outils tiers (par exemple EclipseLink) d'interfacer avec la base de données. Tous les outils tiers n'auront pas la même compréhension d'un "datetime" que MySQL. Vous voulez essayer de comprendre dans Hibernate si vous devez utiliser un objet java.sql.TimeStamp ou java.util.Date si vous utilisez ces types de données personnalisés? L'utilisation de vos types de données de base rend l'utilisation avec des outils tiers triviale.

Ce problème est étroitement lié à la façon dont vous devez stocker une valeur en argent (c.-à-d. 1,99 $) dans une base de données. Devriez-vous utiliser un Decimal, ou le type Money de la base de données, ou le pire de tous les Double? Les trois options sont terribles, pour plusieurs des mêmes raisons énumérées ci-dessus. La solution consiste à stocker la valeur de l'argent en cents en utilisant BIGINT, puis convertir les cents en dollars lorsque vous affichez la valeur à l'utilisateur. Le travail de la base de données est de stocker des données, et de ne pas interpréter ces données. Tous ces types de données fantaisistes que vous voyez dans les bases de données (en particulier Oracle) ajoutent peu, et vous amènent au verrou du fournisseur.


74
2018-06-11 23:02



Cela dépend de l'application, vraiment.

Envisagez de fixer un horodatage par un utilisateur à un serveur à New York, pour un rendez-vous à Sanghai. Maintenant, lorsque l'utilisateur se connecte à Sanghai, il accède au même horodatage de rendez-vous à partir d'un serveur miroir de Tokyo. Il verra le rendez-vous à l'heure de Tokyo, décalé de l'heure originale de New York.

Donc, pour les valeurs qui représentent l'heure de l'utilisateur comme un rendez-vous ou un calendrier, datetime est mieux. Il permet à l'utilisateur de contrôler la date et l'heure exactes, quels que soient les paramètres du serveur. L'heure définie est l'heure définie, n'est pas affectée par le fuseau horaire du serveur, le fuseau horaire de l'utilisateur, ou par les changements dans la façon dont l'heure d'été est calculée (oui, cela change).

D'autre part, pour les valeurs qui représentent l'heure du système comme les transactions de paiement, les modifications de table ou la journalisation, utilisez toujours des horodatages. Le système ne sera pas affecté par le déplacement du serveur vers un autre fuseau horaire ou lors de la comparaison entre des serveurs situés dans des fuseaux horaires différents.

Les horodatages sont également plus légers sur la base de données et indexés plus rapidement.


37
2017-10-26 21:07