Stockage du temps avec des millisecondes dans la base de données

10

Juste une petite question concernant le stockage du "temps" dans une base de données. J'enregistre le temps d'exécution des utilisateurs au format 00: 00: 00: 00 (heures, minutes, secondes, millisecondes).

À l'origine, j'allais le stocker sous, TIMEmais j'ai réalisé que MySQL ne prend pas en charge les millisecondes dans ce type.

Je vais stocker le temps réel pris par le chronomètre des utilisateurs, pas le moment où ils ont couru et fini (cela sera calculé avant d'être inséré).

Quel serait le meilleur type de champ à utiliser? Je pensais à l'un doubleou à l' autre float, mais je ne suis pas sûr que cela fonctionnerait?

mysql best-practices timestamp

— Elliott
source

6

Personnellement, j'utiliserais des types entiers pour la durée

Exemple: 340 000 millisecondes correspondent à 340000 dans une colonne int non signée.

Pour moi, datetime, time, date etc sont pour des points dans le temps explicites. 340 secondes n'a aucun sens dans ce contexte. Avoir un début date/timepermet la durée à ajouter bien sûr

— gbn
source

3

Pour cela, il existe un type de intervaldonnées SQL standard . Mais tous les SGBD (et certainement pas MySQL) ne le supportent pas.

— a_horse_with_no_name

Merci pour votre réponse, aurais-je besoin de le convertir dans un format standard tel qu'il est actuellement au format 00: 00: 00: 00? Puis-je définir la colonne pour autoriser ce type de format?

— Elliott

@Elliott: pour l'affichage, vous pourriez. C'est juste un nombre sinon

— gbn

1

Notez que votre format est probablement (ou devrait être pour la lisibilité) 00: 00: 00.000 (notez le point au lieu des deux points et 3 chiffres pour les millisecondes.

— Jannes

2

Cela dépend de combien de temps vous voulez mesurer. Si vous n'enregistrez pas plus longtemps que 2 ^ 32 ou 4294967296 ms, un int normal non signé est très bien. Cela correspond à environ 50 jours d'horloge, en passant.

Si vous stockiez des horodatages Unix ou des intervalles plus grands, essayez d'utiliser bigint. Cela vous donne 8 octets d'espace, ou la possibilité d'enregistrer des temps aussi longs à 1,84467440737096e + 19 ms (ce qui correspond à environ 500 millions d'années)

— atxdba
source

1

Si vous utilisez MySQL 5.6.4 ou version ultérieure, vous pouvez utiliser le TIME(3), DATETIME(3)et les TIMESTAMP(3)types de colonnes pour stocker jusqu'à 6 décimales (remplacez 3le nombre de décimales dont vous avez besoin). Une partie fractionnaire est ajoutée à la chaîne de temps après le point; exemple: 2018-09-08 17:51:04.781.

Référence officielle

— Délicatesse
source