2010-11-04 14 views
4

J'ai une table de base de données MySQL avec des durées d'exécution de cross country. Je suis à la croisée des chemins et je me demande si je devrais convertir le type de données actuel pour les temps d'exécution (varchar) en nombre décimal. Le seul aspect qui m'attire vers le type de données varchar est que je n'ai pas besoin de convertir les résultats d'exécution entrants (analysés via un script PHP) en secondes, puis de revenir quand il est récupéré dynamiquement. Mon script de traitement assure que chaque fois est de 8 caractères à moins qu'un DNF d'athlète (N'a pas fini) qui est aussi l'information que je voudrais stocker. Le DNF apparaît comme "DNF" dans les résultats.Type de données varchar ou decimal pour les minutes, les secondes et les millisecondes

Donc, une heure de fonctionnement devrait-elle être enregistrée comme suit: 17: 40.57 ou 1060.57? Quels sont les avantages et les inconvénients de chacun? Existe-t-il un meilleur type de données que ce que j'ai déjà supposé comme types corrects? En outre, si vous choisissez 1060.57 comme réponse, comment puis-je logiquement stocker les DNF ou les DNS?

+0

Il serait utile de montrer quel format vous entendez par "17: 40.57" - la plupart supposeront que hh: mm: ss –

+0

Pour les nouveaux utilisateurs: [** Temps de stockage avec millisecondes dans la base de données **] (http : //dba.stackexchange.com/questions/10400/storing-time-with-milliseconds-in-database) –

Répondre

4

J'avais initialement suggéré les types de données TIME et DATETIME, mais je ne savais pas que MySQL does not store microseconds in a column of any temporal data type (IE: TIME, DATETIME, etc). FLOAT est évident pauvre - même les états de MySQL il devrait seulement être employé quand la précision n'est pas un souci.

VARCHAR/CHAR n'est pas une bonne idée, car il n'y a aucun moyen d'imposer la cohérence du format. Vous pourriez mélanger mm: ss: ff et le format décimal - les deux seraient acceptés, mais auraient évidemment l'air bizarre lorsqu'ils sont affichés.

DECIMAL serait le meilleur choix, par souci de cohérence des données & validation compte tenu des limitations de MySQL. Mais cela signifie une fonctionnalité personnalisée pour obtenir des informations si vous voulez un formatage différent, qui aurait été disponible si les fonctions temporelles de MySQL supportaient suffisamment de précision. D'autres bases de données gratuites, comme PostgreSQL, SQL Server Express ou Oracle Express pourraient être considérées comme une alternative pour améliorer la prise en charge des types de données.

+0

cela ne serait-il pas mieux pour hh: mm: ss? c'est mm: ss: ff ... – zen

+0

Je suppose que la pièce décimale est importante, qui ne peut pas être stockée dans un TIME. Si zen veut utiliser TIME, il aura besoin d'une colonne supplémentaire pour les millisecondes. Il a également besoin de colonnes supplémentaires pour les entrées DNF et DNS. – theazureshadow

+0

@theazureshadow: La décimale est juste * formatage/présentation * - c'est ce qui fonctionne comme [TIME_FORMAT] (http://dev.mysql.com/doc/refman/5.1/fr/date-and-time-functions.html# function_time-format) sont pour. –

0

Je le stockerais sous la forme d'un DECIMAL nombre de secondes, avec des colonnes supplémentaires pour stocker les DNF ou les DNS. Si vous le souhaitez, vous pouvez utiliser une seule énumération pour DNF et DNS, car elles sont mutuellement exclusives (en supposant que DNS ne soit pas démarré). Cela permet SUM, arithmétique, etc. Le stockage en tant que VARCHAR ne permet aucun traitement ou filtrage intéressant.

EDIT: a été modifié en DECIMAL pour plus de précision.

+1

Vous ne devez ** jamais ** utiliser les types à virgule flottante pour la devise si vous vous souciez de la précision. Vous rencontrerez toutes sortes d'erreurs d'arrondi et de comparaison étranges. –

+0

Ouais, ne pensait pas (notez l'heure sur l'édition;) – theazureshadow

+0

Je suis heureux avec TIME ou DATETIME, mais vous * ne pouvez pas * stocker des millisecondes, ce qui signifie que zen doit utiliser une colonne séparée. Encore une fois: "microsecondes ne peuvent pas être stockées dans une colonne de type de données temporelles" – theazureshadow