Discussion :

[StringBuilder]

Quelle ne fut pas ma surprise quand j'ai découvert que le type TIME de SQL ne pouvait pas dépasser 24 heures...

Je voudrais stocker dans une colonne un nombre d'heure hebdo (35h, 37h30, etc.)

Le type TIME me séduisait bien, surtout que je vais devoir faire des requêtes en liaison avec des dates. Mais voilà, arrivé à 24h, ça me jette.

Du coup, je me dit "bon, ben va pour un DATETIME, dans lequel je ne vais pas mettre de mois et année...".
Sauf que là, le mois 0 de l'année 0 (et éventuellement le jour 0 pour les contrats de moins de 24 heures), ça marche pas non plus.

Et calculer à partie du 01/01/1900 ça me semble casse-tête chinois à l'avance...

Une solution ?

Du coup j'ai peur de devoir me replier sur DECIMAL (je veux pas entendre parler de FLOAT qui fait des erreurs d'arrondi, et INT c'est pas possible en raison de la présence de décimaux).
Sauf que DECIMAL n'est pas vraiment réputé pour ses performances.

Reste la solution de prendre un INT et multiplier par 60 pour gérer non pas en heures mais en minutes... Mais c'est pas super propre je trouve, et guère moins casse-tête que la solution à base de DATETIME.

Une meilleure idée ?

Pour info, je suis sous SQL Server, au cas où un type tombé du ciel existe sur ce SGBD.

[tatayo]

Bonjour,
Perso je stockerai les minutes (voir les secondes en cas de besoin) dans un INT, la "conversion" en HH:MM:SS relevant plus de la présentation qu'autre chose.

Après tout 15 heures, 900 minutes ou 54000 secondes, c'est la même chose. A charge au programme de restitution de faire les conversions qui vont bien pour que l'utilisateur s'y retrouve.

Tatayo.

[StringBuilder]

Ok. Merci, c'est que je vais faire du coup
En tout cas, c'est ballo cette histoire de 24 heures... Le type "Timespan" de .NET est mieux foutu !

[aieeeuuuuu]

Bonjour,

En effet, le type TIME n'a pas vocation de stocker des durées, mais des heures.

La sémantique n'est pas la même, mais surtout la manipulation :

On peut diviser (par exemple des taches) par 12 heures, mais on ne peut pas diviser par midi...

Cela nous mène au type à utiliser. tout dépend des manipulations que vous allez effectuer ensuite. Si justement vous compter effectuer des divisions, vous aurez aussi des problèmes d'arrondi avec les INT si vous ne prenez pas garde à transtyper en décimal lors de vos calculs. Dans ce cas, un type décimal serait certainement plus approprié. Ses performances ne sont pas si déplorables que ça. Pensez à indiquer une précision (et éventuellement une échelle), la plus petite répondant à votre besoin.

Si vous comptez faire essentiellement des sommes, alors le type INT comme l'a indiqué tatayo est bon aussi.

je veux pas entendre parler de FLOAT qui fait des erreurs d'arrondi

Attention, on peut avoir des erreurs d'arrondi au même titre avec un décimal. Là encore tout dépend des calculs que vous allez effectuer.

[StringBuilder]

J'ai besoin de faire des soustractions : lors de la création d'un planning, je dois décompter les heures planifiées des heures contractuelles afin de ne pas planifier trop d'heures pour un employé. Donc pour 35 heures, avec une granularité de 30 minutes, je me retrouve avec 70 soustractions successives au moment de la création du planning.