DateTime2 vs DateTime dans SQL Server


762

Laquelle:

est le moyen recommandé de stocker la date et l'heure dans SQL Server 2008+?

Je suis conscient des différences de précision (et de l'espace de stockage probablement), mais en les ignorant pour le moment, existe-t-il un document de bonnes pratiques sur le moment d'utiliser quoi, ou peut-être que nous devrions simplement utiliser datetime2uniquement?

Réponses:


641

La documentation MSDN pour datetime recommande d'utiliser datetime2 . Voici leur recommandation:

Utilisez les time, date, datetime2et les datetimeoffsettypes de données pour de nouveaux travaux. Ces types s'alignent sur la norme SQL. Ils sont plus portables. time, datetime2Et datetimeoffset fournir une précision plus secondes. datetimeoffsetfournit un support de fuseau horaire pour les applications déployées à l'échelle mondiale.

datetime2 a une plus grande plage de dates, une plus grande précision fractionnaire par défaut et une précision facultative spécifiée par l'utilisateur. En fonction de la précision spécifiée par l'utilisateur, il peut également utiliser moins de stockage.


46
bien qu'il y ait une précision accrue avec datetime2, certains clients ne prennent pas en charge la date, l'heure ou datetime2 et vous obligent à convertir en un littéral de chaîne. Si vous êtes plus préoccupé par la compatibilité que par la précision, utilisez datetime
FistOfFury

4
Une autre option consiste à utiliser une vue indexée avec la colonne convertie en date-heure pour la compatibilité. Vous devez cependant pouvoir pointer l'application vers la vue.
TamusJRoyce

9
La prise en charge des fuseaux horaires avec DATETIMEOFFSET est un terme impropre. Il stocke uniquement un décalage UTC pour un instant spécifique, pas un fuseau horaire.
Suncat2000

6
@Porad: Quel est exactement l'avantage dans la pratique d'être "" plus portable "en raison du fait qu'il est" SQL Standard "? C'est en plus de vous faire écrire beaucoup plus de code qui est nettement moins lisible / maintenable pour un" port "vers un autre SGBDR qui ne se produira probablement jamais pendant la durée de vie de ce code. À part peut-être les outils et pilotes SQL Server fournis par Microsoft (le cas échéant), existe-t-il des applications qui reposent réellement sur les représentations spécifiques au niveau du bit du DateTime2type (ou de tout autre serveur SQL Server Tapez d'ailleurs) Voir les inconvénients dans ma réponse du 7/10/17 ci-dessous pour savoir pourquoi je demande
Tom

2
@Adam Porad: En outre, tous ces avantages sont probablement inutiles (en dehors des applications d'ingénierie ou scientifiques) et ne valent donc pas beaucoup la perte des avantages, BEAUCOUP plus probablement nécessaires: la capacité beaucoup plus facile (même en tenant compte des solutions de contournement) de se convertir implicitement / explicitement en une valeur numérique à virgule flottante (nombre de jours, le cas échéant, jours fractionnaires depuis la date-heure minimale) pour les ajouts, les soustractions, les minimums, les maximums et les moyennes. Voir les inconvénients dans ma réponse du 7/10/17 ci-dessous pour plus de détails.
Tom

493

DATETIME2a une plage de dates de "0001/01/01" à " DATETIME9999/12/31 " alors que le type ne prend en charge que l'année 1753-9999.

En outre, si vous en avez besoin, vous DATETIME2pouvez être plus précis en termes de temps; DATETIME est limité à 3 1/3 millisecondes, tout en DATETIME2pouvant être précis jusqu'à 100 ns.

Les deux types sont mappés System.DateTimeen .NET - aucune différence là-bas.

Si vous avez le choix, je vous recommande d'utiliser DATETIME2autant que possible. Je ne vois aucun avantage à utiliser DATETIME(sauf pour la compatibilité descendante) - vous aurez moins de problèmes (avec des dates hors limites et des tracas comme ça).

De plus: si vous n'avez besoin que de la date (sans partie horaire), utilisez DATE - c'est aussi bon DATETIME2et économisez de l'espace aussi! :-) Il en va de même pour le temps seulement - utilisez TIME. C'est pour ça que ces types sont là!


158
Soyez prudent lorsque vous ajoutez une valeur .NET DateTime en tant que paramètre à un SqlCommand, car il aime supposer qu'il s'agit de l'ancien type datetime, et vous obtiendrez une erreur si vous essayez d'écrire une valeur DateTime qui se situe en dehors de cette plage d'années 1753-9999 sauf si vous spécifiez explicitement le type comme System.Data.SqlDbType.DateTime2 pour SqlParameter. Quoi qu'il en soit, datetime2 est génial, car il peut stocker n'importe quelle valeur pouvant être stockée dans le type .NET DateTime.
Triynko

10
@marc_s - N'est-ce pas à cela que sert null?
JohnFx

8
@JohnFX - un peu en retard ici - mais vous ne définiriez pas un datetime sur null. vous utiliseriez Nullable <datetime> ou datetime? qui gère null très bien - et dans le mappage à un proc ferait simplement param.value = someDateTime ?? DBValue.Null Son malheureux que nous sommes coincés avec un type de données avec un numéro après - juste semble si « générique »:)
Adam Tuliper - MSFT

69
Lol, j'ai juste essayé de voter pour mon propre commentaire (ci-dessus), avant de réaliser que c'était mon propre commentaire (fait il y a plus d'un an). Je suis toujours confronté à la décision de conception stupide du framework .NET de TRUNCATE toutes les valeurs DateTime par défaut lorsqu'il est passé en tant que SqlParameters, sauf si vous le définissez explicitement sur le SqlDbType.DateTime2 plus précis. Voilà pour déduire automatiquement le bon type. En réalité, ils auraient dû rendre le changement transparent, remplacer l'implémentation à portée limitée moins précise, moins efficace et conserver le nom de type "datetime" d'origine. Voir aussi stackoverflow.com/q/8421332/88409
Triynko

5
@marc_s N'est-ce pas à cela que Nullable<DateTime>sert?
ChrisW

207

datetime2 gagne dans la plupart des aspects sauf (compatibilité des anciennes applications)

  1. une plus grande plage de valeurs
  2. meilleure précision
  3. espace de stockage plus petit (si la précision facultative spécifiée par l'utilisateur est spécifiée)

Comparaison des types de données SQL Date et heure - datetime, datetime2, date, TIME

veuillez noter les points suivants

  • Syntaxe
    • datetime2 [(précision en secondes fractionnaires => Regarder sous la taille de stockage)]
  • Précision, échelle
    • 0 à 7 chiffres, avec une précision de 100ns.
    • La précision par défaut est de 7 chiffres.
  • Taille de stockage
    • 6 octets pour une précision inférieure à 3;
    • 7 octets pour la précision 3 et 4.
    • Toute autre précision nécessite 8 octets .
  • DateTime2 (3) a le même nombre de chiffres que DateTime mais utilise 7 octets de stockage au lieu de 8 octets ( SQLHINTS- DateTime Vs DateTime2 )
  • En savoir plus sur datetime2 (article Transact-SQL MSDN)

source d'image: Kit de formation auto-rythmé des SCTM (examen 70-432): Microsoft® SQL Server® 2008 - Implémentation et maintenance Chapitre 3: Tableaux -> Leçon 1: Création de tableaux -> page 66


7
Merci d'avoir montré que les statistiques +1 pour cela, datetime2c'est génial (Gagnant)
Pankaj Parkar

2
@Iman Abidi: Selon le commentaire d'Oskar Berggren du 10 septembre 2014 à 15h51 sur l'article "SQLHINTS- DateTime Vs DateTime2" auquel vous avez fait référence: "datetime2 (3) n'est PAS le même que datetime. Ils auront le même numéro. des chiffres, mais la précision de datetime est de 3,33 ms, tandis que la précision de datetime2 (3) est de 1 ms. "
Tom

1
@PankajParkar: Woah, pas si vite. Vous voudrez peut-être consulter la section Contre de ma réponse du 7/10/17 ci-dessous.
Tom

Comment datetime2utilise-t-il moins d'espace de stockage datetimeet offre-t-il une gamme plus large et une précision supérieure?
Dai

107

Je suis d'accord avec @marc_s et @Adam_Poward - DateTime2 est la méthode préférée pour aller de l'avant. Il a une plage de dates plus large, une précision plus élevée et utilise un stockage égal ou inférieur (selon la précision).

Une chose la discussion a manqué, mais ...
@Marc_s déclare: Both types map to System.DateTime in .NET - no difference there. C'est correct, cependant, l'inverse n'est pas vrai ... et il est important lors de la recherche de plages de dates (par exemple, "trouvez-moi tous les enregistrements modifiés le 5/5/2010").

La version de .NET Datetimea une portée et une précision similaires à DateTime2. Lors du mappage d'un .net Datetimevers l'ancien SQL, DateTimeun arrondi implicite se produit . L'ancien SQL DateTimeest précis à 3 millisecondes. Cela signifie que 11:59:59.997c'est aussi proche que possible de la fin de la journée. Tout ce qui est supérieur est arrondi au lendemain.

Essaye ça :

declare @d1 datetime   = '5/5/2010 23:59:59.999'
declare @d2 datetime2  = '5/5/2010 23:59:59.999'
declare @d3 datetime   = '5/5/2010 23:59:59.997'
select @d1 as 'IAmMay6BecauseOfRounding', @d2 'May5', @d3 'StillMay5Because2msEarlier'

Éviter cet arrondi implicite est une raison importante pour passer à DateTime2. L'arrondi implicite des dates crée clairement de la confusion:


14
Vous pouvez également éviter cet arrondi en n'essayant pas de trouver la "fin" d'une journée de toute façon. > = 5 mai ET <6 mai est beaucoup plus sûr et fonctionnera sur tous les types de date / heure (sauf TIME bien sûr). Suggérez également d'éviter les formats régionaux ambigus comme m / d / yyyy.
Aaron Bertrand

2
@AaronBertrand - tout à fait d'accord, mais en regardant le nombre de questions que nous avons, il semble que la question mérite d'être décrite.
EBarr

1
Pourquoi êtes-vous passé de 20100505à 5/5/2010? L'ancien format fonctionnera avec n'importe quelle région dans SQL Server. Ce dernier se cassera: SET LANGUAGE French; SELECT Convert(datetime, '1/7/2015')oups:2015-07-01 00:00:00.000
ErikE

1
@EBarr: Re. "DateTime2 est la méthode préférée pour aller de l'avant. Elle a une plage de dates plus large, une précision plus élevée et utilise un stockage égal ou inférieur (selon la précision": je suis fortement en désaccord. Voir la section Cons de ma réponse du 7/10/17 ci-dessous. En bref, ces avantages sont probablement inutiles (en dehors des applications d'ingénierie / scientifiques) et ne valent donc pas la perte d'avantages BEAUCOUP plus probablement nécessaires, la capacité beaucoup plus facile (même en tenant compte des solutions de contournement) de se convertir implicitement / explicitement en un nombre à virgule flottante ( # de jours incl. si appl., fractions depuis min date-heure) valeur pour +, - et moyenne
Tom

20

Presque toutes les réponses et commentaires ont pesé sur les avantages et la lumière sur les inconvénients. Voici un récapitulatif de tous les avantages et inconvénients jusqu'à présent, ainsi que certains inconvénients cruciaux (au n ° 2 ci-dessous) que je n'ai vu mentionnés qu'une seule fois ou pas du tout.

  1. AVANTAGES:

1.1. Plus conforme ISO (ISO 8601) (même si je ne sais pas comment cela entre en jeu dans la pratique).

1.2. Plus de gamme (1/1/0001 au 31/12/9999 vs 1/1 / 1753-12 / 31/9999) (bien que la gamme supplémentaire, toutes antérieures à l'année 1753, ne sera probablement pas utilisée sauf pour ex., dans les applications historiques, astronomiques, géologiques, etc.).

1.3. Correspond exactement à la plage de la plage de type .NET DateTime(bien que les deux convertissent dans les deux sens sans codage spécial si les valeurs sont dans la plage et la précision du type cible, sauf pour Con # 2.1 ci-dessous, sinon une erreur / arrondi se produira).

1.4. Plus de précision (100 nanosecondes aka 0,000,000,1 sec. Contre 3,33 millisecondes aka 0,003,33 sec.) (Bien que la précision supplémentaire ne sera probablement pas utilisée sauf par ex. Dans les applications d'ingénierie / scientifiques).

1.5. Lorsqu'il est configuré pour une précision similaire (comme en 1 millisec pas "identique" (comme en 3,33 millisec) comme Iman Abidi) DateTime, utilise moins d'espace (7 contre 8 octets), mais bien sûr, vous perdriez le avantage de précision qui est probablement l'un des deux (l'autre étant la gamme) les plus vantés bien que probablement des avantages inutiles).

  1. LES INCONVÉNIENTS:

2.1. Lors de la transmission d'un paramètre à un .NET SqlCommand, vous devez spécifier System.Data.SqlDbType.DateTime2si vous pouvez transmettre une valeur en dehors de la DateTimeplage et / ou de la précision de SQL Server , car elle est par défaut System.Data.SqlDbType.DateTime.

2.2. Ne peut pas être implicitement / facilement converti en une valeur numérique à virgule flottante (nombre de jours depuis la date-heure min) pour effectuer les opérations suivantes avec / dans les expressions SQL Server à l'aide de valeurs et d'opérateurs numériques:

2.2.1. ajouter ou soustraire # de jours ou jours partiels. Remarque: L'utilisation de DateAddFunction comme solution de contournement n'est pas anodine lorsque vous devez prendre en compte plusieurs, sinon toutes les parties de la date-heure.

2.2.2. prendre la différence entre deux dates-heures aux fins du calcul de «l'âge». Remarque: Vous ne pouvez pas simplement utiliser la DateDifffonction de SQL Server à la place, car elle ne calcule pas agecomme la plupart des gens s'attendent à ce que si les deux dates-heures arrivent à traverser une limite calendrier / horloge date-heure des unités spécifiées, même pour une petite fraction de cette unité, il retournera la différence que 1 de cette unité par rapport à 0. Par exemple, le DateDiffdans Day« s de deux fois ce jour seulement 1 milliseconde en dehors retournera 1 vs 0 (jours) si ces dates-heures sont sur différents jours civils (c.-à-d. «1999-12-31 23: 59: 59.9999999» et «2000-01-01 00: 00: 00.0000000»). Les mêmes dates-heures de différence de 1 milliseconde si elles sont déplacées afin qu'elles ne traversent pas un jour calendaire, renverront un «DateDiff» en Day's de 0 (jours).

2.2.3. prendre la Avgdate-heure (dans une requête agrégée) en convertissant simplement en «Float» d'abord, puis de nouveau en DateTime.

REMARQUE: pour convertir DateTime2en numérique, vous devez faire quelque chose comme la formule suivante qui suppose toujours que vos valeurs ne sont pas inférieures à l'année 1970 (ce qui signifie que vous perdez toute la plage supplémentaire plus 217 années supplémentaires. Remarque: vous pouvez ne pas être en mesure d'ajuster simplement la formule pour permettre une plage supplémentaire car vous pouvez rencontrer des problèmes de débordement numérique.

25567 + (DATEDIFF(SECOND, {d '1970-01-01'}, @Time) + DATEPART(nanosecond, @Time) / 1.0E + 9) / 86400.0- Source: " https://siderite.dev/blog/how-to-translate-t-sql-datetime2-to.html "

Bien sûr, vous pourriez aussi Castà la DateTimepremière (et si nécessaire de retour à nouveau DateTime2), mais vous perdriez la précision et la portée (tous avant 1753) les prestations de DateTime2rapport DateTimequi sont prolly les 2 plus grands et aussi en même temps prolly les 2 moins probablement nécessaires, ce qui soulève la question de savoir pourquoi l'utiliser lorsque vous perdez les conversions implicites / faciles en virgule flottante numérique (# de jours) pour l'addition / la soustraction / l '"âge" (vs. DateDiff) / le Avgbénéfice de calcul qui est un grand dans mon expérience.

En fait, la Avgdate-heure est (ou du moins devrait être) un cas d'utilisation important. a) Outre l'utilisation pour obtenir la durée moyenne lorsque des dates-heures (car une date-heure de base commune) sont utilisées pour représenter la durée (une pratique courante), b) il est également utile d'obtenir une statistique de type tableau de bord sur ce que la date moyenne- l'heure est dans la colonne date-heure d'une plage / d'un groupe de lignes. c) Une requête ad-hoc standard (ou du moins devrait être standard) pour surveiller / dépanner les valeurs dans une colonne qui peuvent ne plus être valides jamais / plus et / ou qui doivent être dépréciées consiste à répertorier pour chaque valeur le nombre d'occurrences et ( le cas échéant) les Min, Avget Maxhorodatés associés à cette valeur.


1
Comme la vue contraire, elle indique le côté c # de l'équation. Combiné avec tous les autres «pros», il permettra aux gens de faire un bon choix en fonction de l'endroit où ils veulent prendre leur douleur.
EBarr

1
@EBarr: Seule la partie Cons # 1 de ma "'vue contrariante'" "souligne le côté c # de l'équation". Le reste (les inconvénients 2.2.1 - 2.2.3), qui, comme je l'ai dit, sont les avantages (de DateTime) les plus probables , sont tous liés aux effets sur les requêtes et les instructions SQL Server.
Tom

Concernant 2.2.1 - il est considéré comme une pratique dangereuse de faire de l'arithmétique sur les dates, et la meilleure façon est toujours d'utiliser DateAdd et les fonctions connexes. C'est la meilleure pratique. Il y a de sérieux inconvénients à faire de l'arithmétique des dates, et non des moindres, cela ne fonctionne pas pour la plupart des types de dates. Quelques articles: sqlservercentral.com/blogs/… sqlblog.org/2011/09/20/…
RBerman

@RBerman: Re. "dangereux": il n'est dangereux que pour certains types de date (comme celui que DateTime2j'ai déjà mentionné (en raison du risque élevé de débordement)). Ré. "ne fonctionne pas pour la plupart des types de date": vous n'en avez besoin que pour travailler avec un seul, et la plupart des dates dans la plupart des applications n'auront probablement jamais besoin d'être converties en un autre type de date pour toute leur durée de vie (sauf peut-être, comme je l'ai également mentionné , DateTime2à DateTime(par exemple, pour faire de l '"arithmétique sur les dates"; P). Étant donné que cela ne vaut pas tout le codage supplémentaire dans les requêtes de recherche non seulement programmées mais aussi ad hoc pour utiliser un type de date non arithmétique.
Tom

15

DateTime2 fait des ravages si vous êtes un développeur Access essayant d'écrire Now () dans le champ en question. Je viens de faire une migration Access -> SQL 2008 R2 et il a mis tous les champs datetime en DateTime2. Ajout d'un enregistrement avec Now () comme valeur bombardée. C'était correct le 1/1/2012 14:53:04, mais pas le 1/10/2012 14:53:04.

Une fois que le personnage a fait la différence. J'espère que ça aide quelqu'un.


15

Voici un exemple qui vous montrera les différences de taille de stockage (octets) et de précision entre smalldatetime, datetime, datetime2 (0) et datetime2 (7):

DECLARE @temp TABLE (
    sdt smalldatetime,
    dt datetime,
    dt20 datetime2(0),
    dt27 datetime2(7)
)

INSERT @temp
SELECT getdate(),getdate(),getdate(),getdate()

SELECT sdt,DATALENGTH(sdt) as sdt_bytes,
    dt,DATALENGTH(dt) as dt_bytes,
    dt20,DATALENGTH(dt20) as dt20_bytes,
    dt27, DATALENGTH(dt27) as dt27_bytes FROM @temp

qui revient

sdt                  sdt_bytes  dt                       dt_bytes  dt20                 dt20_bytes  dt27                         dt27_bytes
2015-09-11 11:26:00  4          2015-09-11 11:25:42.417  8         2015-09-11 11:25:42  6           2015-09-11 11:25:42.4170000  8

Donc, si je veux stocker des informations à la seconde - mais pas à la milliseconde - je peux enregistrer 2 octets chacun si j'utilise datetime2 (0) au lieu de datetime ou datetime2 (7).


10

bien qu'il y ait une précision accrue avec datetime2 , certains clients ne prennent pas en charge la date , l' heure ou datetime2 et vous obligent à convertir en un littéral de chaîne. Plus précisément, Microsoft mentionne les problèmes ODBC, OLE DB, JDBC et SqlClient de «bas niveau» avec ces types de données et dispose d'un graphique montrant comment chacun peut mapper le type.

Si la valeur de compatibilité sur la précision, utilisez datetime


10

Vieille question ... Mais je veux ajouter quelque chose que personne n'a déjà déclaré ici ... (Remarque: c'est ma propre observation, alors ne demandez aucune référence)

Datetime2 est plus rapide lorsqu'il est utilisé dans les critères de filtre.

TLDR:

Dans SQL 2016, j'avais une table avec cent mille lignes et une colonne datetime ENTRY_TIME car elle était nécessaire pour stocker l'heure exacte jusqu'à quelques secondes. Lors de l'exécution d'une requête complexe avec de nombreuses jointures et une sous-requête, lorsque j'utilisais la clause where comme:

WHERE ENTRY_TIME >= '2017-01-01 00:00:00' AND ENTRY_TIME < '2018-01-01 00:00:00'

La requête était correcte au départ lorsqu'il y avait des centaines de lignes, mais lorsque le nombre de lignes augmentait, la requête commençait à donner cette erreur:

Execution Timeout Expired. The timeout period elapsed prior
to completion of the operation or the server is not responding.

J'ai supprimé la clause where et, de manière inattendue, la requête a été exécutée en 1 seconde, bien que TOUTES les lignes de toutes les dates aient été récupérées. J'exécute la requête interne avec la clause where, et cela a pris 85 secondes, et sans la clause where, cela a pris 0,01 seconde.

Je suis tombé sur de nombreux threads ici pour ce problème en tant que performances de filtrage datetime

J'ai optimisé un peu la requête. Mais la vitesse réelle que j'ai obtenue a été de changer la colonne datetime en datetime2.

Maintenant, la même requête qui a expiré auparavant prend moins d'une seconde.

à votre santé


9

L'interprétation des chaînes de date dans datetimeet datetime2peut également être différente lors de l'utilisation de DATEFORMATparamètres non américains . Par exemple

set dateformat dmy
declare @d datetime, @d2 datetime2
select @d = '2013-06-05', @d2 = '2013-06-05'
select @d, @d2

Cela renvoie 2013-05-06(c'est-à-dire le 6 mai) pour datetimeet 2013-06-05(c'est-à-dire le 5 juin) pour datetime2. Cependant, avec dateformatset to mdy, both @det @d2return 2013-06-05.

Le datetimecomportement semble en contradiction avec la documentation MSDN de SET DATEFORMATqui stipule: Certaines chaînes de caractères formats, par exemple ISO 8601, sont interprétées indépendamment du réglage DATEFORMAT . Evidemment pas vrai!

Jusqu'à ce que je sois mordu par cela, j'avais toujours pensé que les yyyy-mm-dddates seraient juste gérées correctement, quels que soient les paramètres de langue / paramètres régionaux.


2
Nan. Pour ISO 8601, je pense que vous vouliez dire AAAAMMJJ (pas de tirets). SET LANGUAGE FRENCH; DECLARE @d DATETIME = '20130605'; SELECT @d;Réessayez avec les tirets.
Aaron Bertrand

1
La norme autorise les formats AAAA-MM-JJ et AAAAAMMJJ pour les représentations de date du calendrier. Je pense que MSDN devrait être plus précis sur le sous-ensemble de la spécification ISO 8601 qui est interprété indépendamment!
Richard Fawcett

1
Je le sais, mais dans SQL Server, seule la syntaxe sans tiret est sûre.
Aaron Bertrand

6

Selon cet article , si vous souhaitez avoir la même précision que DateTime en utilisant DateTime2, vous devez simplement utiliser DateTime2 (3). Cela devrait vous donner la même précision, prendre un octet de moins et fournir une plage étendue.


Pour être clair, c'est la même précision que SQL datetime, pas un .NET DateTime.
Sam Rueby

C'est exact, j'ai supposé que tout le monde comprendrait le contexte, mais cela vaut la peine d'être précisé.
jKlaus

4

Je suis juste tombé sur un autre avantage pour DATETIME2: cela évite un bogue dans le adodbapimodule Python , qui explose si une datetimevaleur de bibliothèque standard est passée qui a des microsecondes non nulles pour une DATETIMEcolonne mais fonctionne bien si la colonne est définie comme DATETIME2.


0
Select ValidUntil + 1
from Documents

Le SQL ci-dessus ne fonctionnera pas avec un champ DateTime2. Il renvoie et l'erreur "Type d'opérande en conflit: datetime2 est incompatible avec int"

Ajouter 1 pour obtenir le lendemain est quelque chose que les développeurs font avec les dates depuis des années. Maintenant, Microsoft a un nouveau champ datetime2 super qui ne peut pas gérer cette fonctionnalité simple.

"Utilisons ce nouveau type qui est pire que l'ancien", je ne pense pas!


2
Juste pour que nous soyons clairs ici, les types de données datetimeet datetime2ont été introduits dans SQL Server 2008. Vous obtenez également Operand type clash: date is incompatible with intdu datetype qui existe depuis le jour. dateadd(dd, 1, ...)Cependant, les trois types de données fonctionnent très bien.
AlwaysLearning

2
Ce n'est pas clair. J'ai une base de données SQLServer 2005 avec un champ datetime dedans.
Paul McCarthy

0

Je pense que DATETIME2c'est la meilleure façon de stocker le date, car il a plus d'efficacité que le DATETIME. Dans SQL Server 2008vous pouvez utiliser DATETIME2, il stocke une date et une heure, prend 6-8 bytespour stocker et a une précision de 100 nanoseconds. Donc, toute personne qui a besoin d'une plus grande précision temporelle le voudra DATETIME2.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.