Recommanderiez-vous d'utiliser un datetime ou un horodatage champ , et pourquoi (en utilisant MySQL)?
Je travaille avec PHP côté serveur.
Recommanderiez-vous d'utiliser un datetime ou un horodatage champ , et pourquoi (en utilisant MySQL)?
Je travaille avec PHP côté serveur.
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 vouliez décider entre utiliser un horodatage UNIX ou un champ de date / heure MySQL natif, optez pour le format natif. Vous pouvez effectuer 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 horodatage UNIX ("SELECT UNIX_TIMESTAMP(my_datetime)")
lorsque vous interrogez l'enregistrement si vous souhaitez l'utiliser avec PHP.
DATETIME
représente une date (telle que trouvée dans un calendrier) et une heure (comme on peut l'observer sur une horloge murale), tout en TIMESTAMP
représentant un moment bien défini dans le temps. Cela peut être très important si votre application gère les fuseaux horaires. Il y a combien de temps '2010-09-01 16:31:00'? Cela dépend du fuseau horaire dans lequel vous vous trouvez. Pour moi, c'était il y a quelques secondes à peine, pour vous, cela pourrait représenter une époque future. Si je dis 1283351460 secondes depuis '1970-01-01 00:00:00 UTC', vous savez exactement de quel moment je parle. (Voir l'excellente réponse de Nir ci-dessous). [Inconvénient: plage valide].
Dans MySQL 5 et versions ultérieures, les valeurs TIMESTAMP sont converties du fuseau horaire actuel en UTC pour le stockage, et reconverties de l'UTC au fuseau horaire actuel pour la récupération. (Cela se produit uniquement pour le type de données TIMESTAMP et non pour d'autres types tels que DATETIME.)
Par défaut, le fuseau horaire actuel pour chaque connexion est l'heure du serveur. Le fuseau horaire peut être défini pour chaque connexion, comme décrit dans Prise en charge du fuseau horaire du serveur MySQL .
J'utilise toujours les champs DATETIME pour autre chose que des 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 'YYYY-MM-DD HH: MM: SS'. La plage prise en charge est de '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, selon la version de MySQL et le mode SQL dans lequel le serveur s'exécute.
Il est fort probable que vous atteigniez la limite inférieure des TIMESTAMPs en général - par exemple, le stockage de la date de naissance.
new Date().getTime()
vous donne déjà une valeur 64 bits.
Les exemples ci-dessous montrent comment le TIMESTAMP
type de date a changé les valeurs après avoir changé time-zone to 'america/new_york'
où DATETIME
est 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 Timestamp Data Types .
DATETIME
temps effectif a changé avec le changement de fuseau horaire, TIMESTAMP
n'a pas changé, mais la représentation humaine a changé.
set time_zone="america/new_york"
;
La principale différence est que DATETIME est constant tandis que TIMESTAMP est affecté par le time_zone
paramètre.
Cela n'a donc d'importance que lorsque vous avez - ou pourriez avoir à l'avenir - des clusters synchronisés sur plusieurs fuseaux horaires.
En termes plus simples: si j'ai une base de données en Australie et que je fais un vidage de cette base de données pour synchroniser / remplir une base de données en Amérique, le TIMESTAMP serait mis à jour pour refléter l'heure réelle de l'événement dans le nouveau fuseau horaire, tandis que DATETIME reflètent toujours l'heure de l'événement dans le fuseau horaire de l'UA .
Un excellent exemple d'utilisation de DATETIME là où TIMESTAMP aurait dû être utilisé est sur Facebook, où leurs serveurs ne sont jamais tout à fait sûrs de ce qui s'est passé entre les fuseaux horaires. Une fois, j'ai eu une conversation dans laquelle le temps a dit que je répondais aux messages avant que le message ne soit envoyé. (Bien sûr, cela pourrait également être dû à une mauvaise traduction du fuseau horaire dans le logiciel de messagerie si les heures étaient affichées plutôt que synchronisées.)
Je prends cette décision sur une base sémantique.
J'utilise un horodatage lorsque j'ai besoin d'enregistrer un point fixe (plus ou moins) dans le temps. Par exemple, lorsqu'un enregistrement a été inséré dans la base de données ou lorsqu'une action 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 des rendez-vous de modification ultérieurs.
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é à enregistrer 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 présente plusieurs avantages:
Ce problème est étroitement lié à la façon dont vous devez stocker une valeur monétaire (c'est-à-dire 1,99 $) dans une base de données. Devez-vous utiliser un Decimal, ou le type Money de la base de données, ou pire encore un Double? Ces 3 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 à l'aide de BIGINT, puis à convertir les cents en dollars lorsque vous affichez la valeur à l'utilisateur. Le travail de la base de données consiste à stocker des données et NON à interpréter ces données. Tous ces types de données sophistiqués que vous voyez dans les bases de données (en particulier Oracle) ajoutent peu et vous lancent sur la voie du verrouillage des fournisseurs.
TIMESTAMP est de 4 octets contre 8 octets pour DATETIME.
http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html
Mais comme le dit scronide, il a une limite inférieure de l'année 1970. C'est bien pour tout ce qui pourrait arriver à l'avenir;)
TIMESTAMP est de quatre octets contre huit octets pour DATETIME.
Les horodatages sont également plus légers sur la base de données et indexés plus rapidement.
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 'YYYY-MM-DD HH: MM: SS'. La plage prise en charge est de '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, selon la version de MySQL et le mode SQL dans lequel le serveur s'exécute.
Cela dépend de l'application, vraiment.
Pensez à définir un horodatage par un utilisateur sur un serveur à New York, pour un rendez-vous à Sanghai. Désormais, lorsque l'utilisateur se connecte à Sanghai, il accède au même horodatage de rendez-vous à partir d'un serveur en miroir à Tokyo. Il verra le rendez-vous à l'heure de Tokyo, décalé de l'heure d'origine de New York.
Ainsi, pour les valeurs qui représentent le temps de l'utilisateur comme un rendez-vous ou un horaire, datetime est meilleur. Il permet à l'utilisateur de contrôler la date et l'heure exactes souhaitées, quels que soient les paramètres du serveur. L'heure définie est l'heure définie, non 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, elle change).
D'un autre côté, pour les valeurs qui représentent l'heure 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 dans des fuseaux horaires différents.
Les horodatages sont également plus légers sur la base de données et indexés plus rapidement.
Tout framework frontal récent (Angular 1/2, react, Vue, ...) peut facilement et automatiquement convertir votre datetime UTC en heure locale.
Aditionellement:
(Sauf si vous êtes susceptible de modifier le fuseau horaire de vos serveurs)
Exemple avec 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' }}
Tous les formats d'heure localisés sont disponibles ici: https://docs.angularjs.org/api/ng/filter/date
SET time_zone = '+0:00';
pour UTC.
Un timestamp
champ est un cas particulier du datetime
champ. Vous pouvez créertimestamp
colonnes pour avoir des propriétés spéciales; il peut être configuré pour se mettre à jour lors de la création et / ou de la mise à jour.
En termes de base de données "plus grande", timestamp
contient quelques déclencheurs de cas spéciaux.
Le bon choix dépend entièrement de ce que vous voulez faire.
TIMESTAMP est toujours en UTC (c'est-à-dire en secondes écoulées depuis le 01/01/1970, en UTC), et votre serveur MySQL le convertit automatiquement en date / heure pour le fuseau horaire de connexion. À long terme, TIMESTAMP est la voie à suivre car vous savez que vos données temporelles seront toujours en UTC. Par exemple, vous ne bousillerez pas vos dates si vous migrez vers un autre serveur ou si vous modifiez les paramètres de fuseau horaire sur votre serveur.
Remarque: le fuseau horaire de connexion par défaut est le fuseau horaire du serveur, mais il peut (devrait) être modifié par session (voir SET time_zone = ...
).
Comparaison entre DATETIME, TIMESTAMP et DATE
Quelle est cette [.fraction]?
Sources:
J'utiliserais toujours un horodatage Unix pour travailler avec MySQL et PHP. La raison principale en est la date par défaut méthode de en PHP utilise un horodatage comme paramètre, donc aucune analyse syntaxique n'est nécessaire.
Pour obtenir l'horodatage Unix actuel en PHP, faites-le time();
et faites -le dans MySQL SELECT UNIX_TIMESTAMP();
.
Il convient de noter que dans MySQL, vous pouvez utiliser quelque chose dans le sens ci-dessous lors de la création de vos colonnes de table:
on update CURRENT_TIMESTAMP
Cela mettra à jour l'heure à laquelle vous modifiez une ligne à chaque instance et est parfois très utile pour les informations de dernière modification stockées. Cela ne fonctionne qu'avec horodatage, pas datetime cependant.
D'après mon expérience, si vous voulez un champ de date dans lequel l'insertion ne se produit qu'une seule fois et que vous ne voulez pas avoir de mise à jour ou toute autre action sur ce champ particulier, choisissez la date et l'heure .
Par exemple, considérons une user
table avec un champ DATE D'ENREGISTREMENT . Dans ce user
tableau, si vous souhaitez connaître la dernière heure de connexion d'un utilisateur particulier, utilisez un champ de type horodatage pour que le champ soit mis à jour.
Si vous créez la table à partir de phpMyAdmin, le paramètre par défaut mettra à jour le champ d' horodatage lorsqu'une mise à jour de ligne se produit. Si votre horodatage déposé ne se met pas à jour avec la mise à jour des lignes, vous pouvez utiliser la requête suivante pour que le champ d' horodatage soit automatiquement mis à jour.
ALTER TABLE your_table
MODIFY COLUMN ts_activity TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP;
Le type de données d'horodatage stocke la date et l'heure, mais au format UTC, pas au format de fuseau horaire actuel comme le fait datetime. Et lorsque vous récupérez des données, l'horodatage les convertit à nouveau dans le fuseau horaire actuel.
Supposons donc que vous vous trouviez aux États-Unis et que vous obteniez des données d'un serveur dont le fuseau horaire est celui des États-Unis. Ensuite, vous obtiendrez la date et l'heure en fonction du fuseau horaire des États-Unis. La colonne de type de données d'horodatage est toujours mise à jour automatiquement lorsque sa ligne est mise à jour. Il peut donc être utile de suivre quand une ligne particulière a été mise à jour la dernière fois.
Pour plus de détails, vous pouvez lire l'article de blog Timestamp Vs Datetime .
SET time_zone = '+0:00';
(UTC ici) pour être sûr de ce que vous obtenez / définissez à partir des TIMESTAMP
valeurs et éviter de dépendre du serveur time_zone par défaut qui pourrait changer.
J'utilise toujours un horodatage Unix, simplement pour maintenir la raison lorsque je traite de nombreuses informations datetime, en particulier lors de l'ajustement des fuseaux horaires, de l'ajout / de la soustraction de dates, etc. Lorsque vous comparez des horodatages, cela exclut les facteurs de complication du fuseau horaire et vous permet d'économiser des ressources dans votre traitement côté serveur (que ce soit le code d'application ou les requêtes de base de données) en ce que vous utilisez l'arithmétique légère plutôt que d'ajouter / soustraire une date / heure plus lourde. les fonctions.
Une autre chose à considérer:
Si vous créez une application, vous ne savez jamais comment vos données peuvent être utilisées sur toute la ligne. Si vous devez comparer, par exemple, un ensemble d'enregistrements dans votre ensemble de données avec, par exemple, un ensemble d'éléments d'une API tierce, et dire, les mettre dans l'ordre chronologique, vous serez heureux d'avoir Horodatages Unix pour vos lignes. Même si vous décidez d'utiliser les horodatages MySQL, stockez un horodatage Unix comme assurance.
Dans mon cas, j'ai défini UTC comme fuseau horaire pour tout: le système, le serveur de base de données, etc. chaque fois que je le peux. Si mon client a besoin d'un autre fuseau horaire, je le configure sur l'application.
Je préfère presque toujours les horodatages plutôt que les champs datetime, car les horodatages incluent implicitement le fuseau horaire. Donc, depuis le moment où l'application sera accessible à partir d'utilisateurs de différents fuseaux horaires et que vous souhaitez qu'ils voient les dates et les heures dans leur fuseau horaire local, ce type de champ le rend assez facile à faire que si les données étaient enregistrées dans des champs datetime .
En plus, dans le cas d'une migration de la base de données vers un système avec un autre fuseau horaire, je me sentirais plus en confiance en utilisant des horodatages. Pour ne pas dire les problèmes possibles lors du calcul des différences entre deux moments avec un changement d'heure entre les deux et nécessitant une précision de 1 heure ou moins.
Donc, pour résumer, j'apprécie les avantages de l'horodatage:
Pour toutes ces raisons, je choisis les champs UTC et d'horodatage lorsque cela est possible. Et j'évite les maux de tête;)
warranties.expires_at
ne pouvait pas être un horodatage MySQL aujourd'hui.
Méfiez-vous des modifications d'horodatage lorsque vous effectuez une instruction UPDATE sur une table. Si vous avez une table avec des colonnes 'Name' (varchar), 'Age' (int) et 'Date_Added' (horodatage) et que vous exécutez l'instruction DML suivante
UPDATE table
SET age = 30
puis chaque valeur unique dans votre colonne "Date_Added" serait remplacée par l'horodatage actuel.
ON UPDATE CURRENT_TIMESTAMP
Référence tirée de cet article:
Les principales différences:
TIMESTAMP permet de suivre les modifications apportées aux enregistrements et de les mettre à jour chaque fois que l'enregistrement est modifié. DATETIME utilisé pour stocker une valeur spécifique et statique qui n'est affectée par aucun changement dans les enregistrements.
TIMESTAMP est également affecté par différents paramètres liés à TIME ZONE. DATETIME est constant.
TIMESTAMP a converti en interne le fuseau horaire actuel en UTC pour le stockage et, pendant la récupération, reconverti dans le fuseau horaire actuel. DATETIME ne peut pas faire cela.
Plage prise en charge par TIMESTAMP: '1970-01-01 00:00:01 ′ UTC à' 2038-01-19 03:14:07 'UTC DATETIME plage prise en charge:' 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. |
+---------------------------------------------------------------------------------------+--------------------------------------------------------------------------+
Une autre différence entre l'horodatage et la date et l'heure réside dans l'horodatage dont la valeur par défaut est NULL.
CREATE TABLE t2 ( ts1 TIMESTAMP NULL, ts2 TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP);
La première colonne peut accepter une valeur NULL.
J'ai trouvé une utilité inégalée dans la capacité de TIMESTAMP à se mettre à jour automatiquement en fonction de l'heure actuelle sans utiliser de déclencheurs inutiles. C'est juste moi cependant, bien que TIMESTAMP soit UTC comme il a été dit.
Il peut garder une trace sur différents fuseaux horaires, donc si vous devez afficher une heure relative par exemple, l'heure UTC est ce que vous souhaitez.
La principale différence est
regardez ce post pour voir les problèmes d'indexation Datetime
J'ai cessé d'utiliser datetime
dans mes applications après avoir rencontré de nombreux problèmes et bugs liés aux fuseaux horaires. À mon humble avis, l'utilisation timestamp
est meilleure que datetime
dans la plupart des cas .
Quand vous demandez quel est le temps? et la réponse vient comme quelque chose comme '2019-02-05 21:18:30', qui n'est pas terminée, pas de réponse définie car il manque une autre partie, dans quel fuseau horaire? Washington? Moscou? Pékin ?
L'utilisation d'heures sans le fuseau horaire signifie que votre application ne traite que d'un seul fuseau horaire, mais les horodatages vous offrent les avantages datetime
et la flexibilité d'afficher le même moment exact dans différents fuseaux horaires.
Voici quelques cas qui vous feront regretter d'utiliser datetime
et souhaiteront avoir stocké vos données dans des horodatages.
Pour le confort de vos clients, vous voulez leur montrer les heures en fonction de leurs fuseaux horaires préférés sans les obliger à faire le calcul et convertir l'heure en leur fuseau horaire significatif. tout ce dont vous avez besoin est de changer le fuseau horaire et tout votre code d'application sera le même. (En fait, vous devez toujours définir le fuseau horaire au début de l'application, ou demander un traitement dans le cas d'applications PHP)
SET time_zone = '+2:00';
vous avez changé le pays dans lequel vous séjournez et poursuivez votre travail de maintenance des données tout en les visualisant dans un fuseau horaire différent (sans modifier les données réelles).
datetime
= l'application prend en charge 1 fuseau horaire (pour l'insertion et la sélection)
timestamp
= l'application prend en charge n'importe quel fuseau horaire (pour l'insertion et la sélection)
Cette réponse est uniquement pour mettre en évidence la flexibilité et la facilité des horodatages en ce qui concerne les fuseaux horaires, elle ne couvre pas d'autres différences telles que la taille ou la plage de colonnes ou la fraction .
date
et d'autres champs utilisent timestamp
dans une table. Je pense que cela causera un nouveau problème car les données filtrées where
ne sont pas conformes aux changements de fuseau horaire.
date
colonne avant d'envoyer la requête.
A TIMESTAMP
nécessite 4 octets, tandis que a DATETIME
requiert 8 octets.
J'aime un horodatage Unix, car vous pouvez convertir en nombres et vous soucier du nombre. De plus, vous ajoutez / soustrayez et obtenez des durées, etc. Convertissez ensuite le résultat en Date dans n'importe quel format. Ce code découvre combien de temps en minutes s'est écoulé entre un horodatage d'un document et l'heure actuelle.
$date = $item['pubdate']; (etc ...)
$unix_now = time();
$result = strtotime($date, $unix_now);
$unix_diff_min = (($unix_now - $result) / 60);
$min = round($unix_diff_min);