La taille de dateTime2 (0), dateTime2 (1), dateTime2 (2), dateTime2 (3) utilise la même quantité de stockage. (6 octets)
Aurais-je raison de dire que je pourrais aussi bien aller avec dateTime2 (3) et bénéficier de la précision sans coûts de taille supplémentaires.
Non, vous avez mal interprété la documentation. Notez que le document indique une taille de stockage de 6 octets pour les précisions inférieures à 3 (accentuation du mien). Une précision égale à 3 nécessitera donc 7 octets.
Si vous ne vous souciez pas des millisecondes, ce datetime2(0)serait le type de données et la précision appropriés. La meilleure pratique consiste à spécifier le type de données et la précision appropriés en fonction des données stockées car cela fournira intrinsèquement un stockage et une efficacité optimaux. Cela étant dit, je ne m'attendrais pas à un impact significatif sur les performances basé sur la précision de datetime2 spécifiée tant que la taille de stockage est la même, mais je ne l'ai pas spécifiquement testé moi-même.
Les exigences de l'application dicteront ce qui doit être stocké dans la base de données lorsqu'une plus grande précision est disponible dans la source. Par exemple, pour une heure d'entrée de commande provenant de SYSDATETIME(), les utilisateurs peuvent ne pas souhaiter une précision de 100 nanosecondes. Encore une fois, choisissez le type de données et la précision pour un nouveau développement en fonction des besoins et vous obtiendrez généralement des performances optimales sans réflexion supplémentaire:
- date - vous n'avez pas besoin de temps
- smalldatetime - vous n'avez pas besoin de secondes
- datetime2 (0) - vous n'avez pas besoin de secondes fractionnaires
- datetime2 (1-7) - vous avez besoin de fractions de seconde de la précision spécifiée
- datetimeoffset (0-7) - vous avez besoin de la date et de l'heure avec connaissance du fuseau horaire
- heure (0-7) - vous avez besoin uniquement de l'heure (pas de date) avec des fractions de seconde de la précision spécifiée
Bien que datetime2 soit le plus approprié pour les nouveaux développements énumérés ci-dessus, il peut parfois être nécessaire d'utiliser datetime (précision fixe 3 avec une précision de 1/300 de fraction de seconde) à la place pour la compatibilité avec les applications datetime héritées, évitant ainsi les conversions implicites et les comportements de comparaison inattendus, mais à le coût d'une précision fractionnaire et d'un stockage accru.
Considérez que le stockage d'une précision supérieure à celle requise peut également avoir un coût de développement. Si l'on stocke une composante temporelle avec des secondes fractionnaires alors que seule une précision de seconde entière est requise, les requêtes devront toujours prendre en compte les secondes fractionnaires pour renvoyer les résultats corrects. Par exemple, avec une application dans laquelle l'utilisateur sélectionne une plage de temps via une interface utilisateur qui n'autorise que des secondes entières, le code de l'application devrait tenir compte des secondes fractionnaires dans la plage de temps de fin et ajuster la valeur fournie par l'utilisateur en conséquence (par exemple, WHERE OrderEntryTime BETWEEN '2017-01-11T08:00:00.00.00' AND '2017-01-11T08:59:59.99'ou WHERE OrderEntryTime >= '2017-01-11T08:00:00.00' AND OrderEntryTime < '2017-01-11T09:00:00.00'). Cela ajoutera de la complexité au code.