À l'aide de MySQL TIMESTAMP vs stocker les horodatages directement

Je suis dans un dilemme sur l'enregistrement de la date et de l'heure dans MySQL format d'HORODATAGE vs personnalisé dans un UNSIGNED INT format. Les principales considérations sont la vitesse de récupération, de la plage appropriée calculs en PHP et occasionnel de la mise en forme dans, lisible par les valeurs.

L'espace de stockage requis pour chaque type et leurs gammes:

DATETIME        8 bytes  '1000-01-01 00:00:00' to '9999-12-31 23:59:59'
TIMESTAMP       4 bytes  '1970-01-01 00:00:01' UTC to '2038-01-19 03:14:07' UTC
UNSIGNED INT    4 bytes  (Maximum Value 4294967295)

Je n'ai pas besoin de la gamme de date à tous. Je suis déchiré entre l'HORODATAGE et la UNSIGNED INT.

Arguments en faveur d'un UNSIGNED INT:

  • Un timestamp UNIX de 4294967295 convertit à la Sun, 07 Feb 2106 06:28:15 GMT qui est plus que l'HORODATAGE et assez bon pour moi
  • De la comparaison de ces horodatages directement en PHP serait plus rapide, plutôt que de convertir les Horodatages via la fonction strtotime (), puis en les comparant

Le seul avantage d'HORODATAGE me donnerait, c'est quand je suis en train de lire dans les valeurs de la table mysql manuellement et ont besoin de "voir" leur.

Est-il une raison impérieuse d'utiliser l'HORODATAGE et pas un UNSIGNED INT?

  • Voir: datetime vs timestamp?
  • Un 32bit timestamp ne va pas jusqu'à janvier 2038, et de nombreuses bibliothèques sont encore en utilisant 32 bits time_t lieu de 64 bits, de sorte que vous pouvez courir dans des problèmes de portabilité. En interne, PHP stocke les horodateurs/datetime au format numérique, de toute façon, et convertit uniquement à la belle aaaa-mm-jj type de cordes sur la récupération.
InformationsquelleAutor siliconpi | 2011-08-11
  1. 25

    Arguments pour TIMESTAMP

    • Implicitement stocke les données dans le fuseau horaire UTC. Quel que soit votre durée d'une session de la zone est. Utile si vous devez utiliser des fuseaux horaires différents.
    • Vous pouvez avoir automatisé horodatage colonnes à l'aide de DEFAULT CURRENT_TIMESTAMP ou ON UPDATE CURRENT_TIMESTAMP (une colonne par table jusqu'à ce que MySQL 5.6.5)
    • Vous pouvez utiliser datetime fonction de la date de comparaison, addition, la soustraction, la plage de recherche, etc, sans avoir à utiliser FROM_UNIXTIME() la fonction, c'est plus facile d'écrire des requêtes qui peuvent utiliser les index

    • En PHP 

      >> date('Y-m-d h:i:s',4294967295);
'1969-12-31 11:59:59'

      donc la plage est en fait la même

    Quand UNIX_TIMESTAMP() est utilisée sur une colonne de type TIMESTAMP, la fonction
    renvoie l'intérieur d'horodatage valeur directement, sans implicite
    “string-to-Unix timestamp” conversion

    • echo date('Y-m-d h:i:s',4294967295); pour moi donne 2106-02-07 06:28:15 - êtes-vous à l'aide d'un 32-bit OS?
    • Non, c'est une 64b Windows, mais je pense que j'ai un 32b PHP en cours d'exécution. Il est soomething vous devez prendre en compte si vous souhaitez que votre demande soit portable. Si vous avez le contrôle sur la production de l'environnement, alors passons.
    • Quant à votre deuxième point, une seule colonne peut être fait par DÉFAUT CURRENT_TIMESTAMP ou SUR la mise à JOUR CURRENT_TIMESTAMP, comme l'a souligné ici (au moins sur MySQL v5.1): dev.mysql.com/doc/refman/5.1/en/timestamp-initialization.html
    • Rymland: Qui est à droite. Cela change avec MySQL 5.6.5, qui ajoute également autoinit valeurs pour le type de données DATETIME. dev.mysql.com/doc/refman/5.6/en/timestamp-initialization.html
    • Ne devrait pas horodateurs être stockées que l'UTC?
    • Ils sont. Dans la réponse ci-dessus, j'ai écrit c'est GMT, mais c'est en fait l'UTC.

    InformationsquelleAutor Mchl
  2. 9

    La seule réelle utilité pour le TIMESTAMP, c'est quand vous voulez que le champ sera mis à jour automatiquement lorsque la ligne est mise à jour (ce qui est le comportement par défaut pour ce champ), ou lorsque les besoins de stockage de données sont tellement strictes que 4 octets par ligne fait vraiment une différence pour vous.

    Vraiment la comparaison doit être entre DATETIME et UNSIGNED INT, et je le recommande DATETIME parce que:

    • Vous pouvez utiliser MySQL native de la date/fonctions de temps pour la sélection par plage de dates, etc.
    • Il est trivial pour sélectionner ces dates comme des timestamps UNIX pour faciliter la mise en forme en PHP: SELECT UNIX_TIMESTAMP(field) FROM table, pas besoin de sélectionner la valeur brute et utiliser la fonction strtotime
    • Plus facile de lire et de modifier les champs de votre base de données directement en cas de besoin (comme vous l'avez souligné).
    • Pas de limitations sur la plage de dates

    Point deux seuls vraiment enlève toute raison de stocker des nombres entiers, à mon avis.

    • L'inconvénient pour le type DATETIME est qu'il ne stocke pas le décalage GMT dans le domaine. Vous avez besoin de convertir tout avant de le ranger à l'heure GMT (ou ce que vous voulez de votre "zoulou" le temps de l'être) et puis le convertir en arrière si vous avez affaire à plusieurs fuseaux horaires. Le stockage en INT supprime certaines de ces exigences.
    • Un avantage pour le type DATETIME est que je suis paresseux et il fonctionne très bien pour une seule localité/fuseau horaire.
    • Merci pour le commentaire sur UNIX_TIMESTAMP je ne le savais pas avant maintenant.
    • J'ai été stocker tout comme un unsigned int Carbone DateTime bibliothèque... ce qui est intéressant informations à prendre en compte. +1!
    • Comment faire face à l'heure d'été si vous utilisez la méthode DATETIME? Lorsque nous rembobiner l'horloge d'une heure, nous arrivons à la même heure que d'une heure plus tôt. Vous n'avez pas ce problème potentiel avec le temps Unix.
    • Je considère que c'est la meilleure pratique pour stocker tout à l'heure UTC. Si vous magasin local de fuseaux horaires, il faut également être en mesure de déterminer le fuseau horaire pour gérer les différences de temps et de l'heure d'été. Je pense que si vous voulez stocker les valeurs DATETIME à partir de plusieurs fuseaux horaires locaux et en quelque sorte de ne pas être en mesure d'obtenir le fuseau horaire que vous auriez beaucoup plus de problèmes que de traiter avec l'heure d'été.

    InformationsquelleAutor Tim Fountain
  3. 3

    Cela pourrait ne pas être un "scientifique" réponse mais je trouve toujours le moyen de MySql gère la conversion, de l'arithmétique, comparaison, etc... sur les colonnes de type TIMESTAMP à confusion. Un UNSIGNED INT colonne est beaucoup plus simple et je sais toujours à quoi s'attendre.

    P. S. peut-être une autre chose en faveur de la colonne TIMESTAMP, c'est sa capacité à être automatiquement défini à l'heure actuelle, après chaque mise à jour ou insérez mais ce n'est pas quelque chose que vous ne pouvez pas vivre sans.

    InformationsquelleAutor nobody