datetime2 (0) vs datetime2 (2)
Selon la documentation datetime2 (Transact-SQL) :
Taille de stockage
6 octets pour les précisions inférieures à 3.
7 octets pour les précisions 3 et 4.
Toutes les autres précisions nécessitent 8 octets.
La taille de datetime2(0), datetime2(1), datetime2(2) utilise la même quantité de stockage (6 octets).
Aurais-je raison de dire que je pourrais aussi bien aller avec datetime2(2) et bénéficier de la précision sans coûts de taille supplémentaires?
Notez s'il vous plaît:
- Cette colonne est indexée avec le PK pour former un index cluster composé (utilisé pour le partitionnement de table)
- Je me fiche des millisecondes
Est-ce que datetime2(0) serait plus efficace en termes de processeur lorsqu'elle est utilisée dans une clause where ou lors de la recherche via un index?
Il s'agit d'un tableau massif, donc la plus petite optimisation fera une grande différence.
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 taille de stockage 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, 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 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 de saisie 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 seulement besoin 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 un comportement de comparaison inattendu, mais au détriment de la précision de la fraction de seconde et du 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 un composant de temps 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 retourner les résultats corrects. Par exemple, avec une application où 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 devra 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.