Question Comment retourner uniquement la date à partir d'un type de données SQL Server DateTime


SELECT GETDATE()

Résultats: 2008-09-22 15:24:13.790

Je veux cette partie de date sans la partie de temps: 2008-09-22 00:00:00.000

Comment puis-je l'obtenir?


1404
2017-09-22 03:31


origine


Réponses:


Sur SQL Server 2008 et plus haut, vous devriez CONVERT à ce jour:

SELECT CONVERT(date, getdate())

Sur les anciennes versions, vous pouvez effectuer les opérations suivantes:

SELECT DATEADD(dd, 0, DATEDIFF(dd, 0, @your_date))

par exemple

SELECT DATEADD(dd, 0, DATEDIFF(dd, 0, GETDATE()))

Donne moi

2008-09-22 00:00:00.000

Avantages:

  • Non varchar<->datetime conversions requises
  • Pas besoin de penser à locale

2056
2017-09-22 03:34



SQLServer 2008 a maintenant un type de données 'date' qui contient uniquement une date sans composant heure. Toute personne utilisant SQL Server 2008 et les versions ultérieures peut effectuer les opérations suivantes:

SELECT CONVERT(date, GETDATE())

657
2017-09-24 13:02



Si vous utilisez SQL 2008 et plus:

select cast(getdate() as date)

141
2018-01-31 09:44



DATEADD et DATEDIFF sont meilleurs que CONVERTing en varchar. Les deux requêtes ont le même plan d'exécution, mais les plans d'exécution concernent principalement Les données stratégies d'accès et ne révèlent pas toujours les coûts implicites impliqués dans le temps CPU pris pour effectuer toutes les pièces. Si les deux requêtes sont exécutées sur une table avec des millions de lignes, l'heure du processeur en utilisant DateDiff peut être proche de 1/3 du temps CPU Convert!

Pour voir les plans d'exécution des requêtes:

set showplan_text on
GO 

DATEADD et DATEDIFF exécuteront un CONVERT_IMPLICIT.

Bien que la solution CONVERT soit plus simple et plus facile à lire pour certains, elle est Ralentissez. Il n'est pas nécessaire de renvoyer vers datetime (ceci est implicitement effectué par le serveur). Il n'y a pas non plus de besoin réel dans la méthode DateDiff pour DateAdd, car le résultat entier sera également implicitement converti en datetime.


SELECT CONVERT (varchar, MyDate, 101) FROM DatesTable

  |--Compute Scalar(DEFINE:([Expr1004]=CONVERT(varchar(30),[TEST].[dbo].[DatesTable].[MyDate],101)))
       |--Table Scan(OBJECT:([TEST].[dbo].[DatesTable]))

SELECT DATEADD (jj, 0, DATEDIFF (jj, 0, MyDate)) FROM DatesTable

  |--Compute Scalar(DEFINE:([Expr1004]=dateadd(day,(0),CONVERT_IMPLICIT(datetime,datediff(day,'1900-01-01 00:00:00.000',CONVERT_IMPLICIT(datetime,[TEST].[dbo].[DatesTable].[MyDate],0)),0))))
       |--Table Scan(OBJECT:([TEST].[dbo].[DatesTable]))

L'utilisation de FLOOR () comme suggéré par @digi a des performances plus proches de DateDiff, mais n'est pas recommandée car la conversion du type de données datetime en float et back ne donne pas toujours la valeur d'origine.

Rappelez-vous les gars: Ne croyez personne. Regardez les statistiques de performance, et testez vous-même!

Soyez prudent lorsque vous testez vos résultats. La sélection de nombreuses lignes pour le client masquera la différence de performance car il faut plus de temps pour envoyer les lignes sur le réseau que pour effectuer les calculs. Assurez-vous donc que le travail pour toutes les lignes est effectué par le serveur, mais qu'aucun ensemble de lignes n'est envoyé au client.

Il semble y avoir de la confusion pour certaines personnes à propos de l'optimisation du cache qui affecte les requêtes. L'exécution de deux requêtes dans le même lot ou dans des lots séparés n'a aucun effet sur la mise en cache. Vous pouvez donc soit expirer le cache manuellement, soit simplement exécuter les requêtes plusieurs fois. Toute optimisation pour la requête n ° 2 affecterait également les requêtes suivantes, donc jetez l'exécution n ° 1 si vous le souhaitez.

Voici script de test complet et résultats de performance Cela prouve que DateDiff est sensiblement plus rapide que la conversion en varchar.


67
2017-09-22 03:33



SELECT CONVERT(VARCHAR(10),GETDATE(),111)

41
2017-09-22 03:33



SELECT CONVERT(datetime, CONVERT(varchar, GETDATE(), 101))

35
2017-09-22 03:34



Vous pouvez utiliser le CONVERT Fonction pour retourner uniquement la date. Voir le lien (s) ci-dessous:

Manipulation de la date et de l'heure dans SQL Server 2000

CAST et CONVERT

La syntaxe pour utiliser la fonction de conversion est:

CONVERT ( data_type [ ( length ) ] , expression [ , style ] ) 

18
2017-12-19 06:48



Pour le retour au format de date 

CAST (OrderDate AS date)

Le code ci-dessus fonctionnera dans SQL Server 2010

Il reviendra comme 12/12/2013

Pour SQL Server 2012, utilisez le code ci-dessous

CONVERT(VARCHAR(10), OrderDate , 111)

17
2017-09-22 07:38



En utilisant FLOOR () - il suffit de couper la partie temps.

SELECT CAST(FLOOR(CAST(GETDATE() AS FLOAT)) AS DATETIME)

12
2017-09-22 12:21



SELECT CONVERT(VARCHAR,DATEADD(DAY,-1,GETDATE()),103) --21/09/2011

SELECT CONVERT(VARCHAR,DATEADD(DAY,-1,GETDATE()),101) --09/21/2011

SELECT CONVERT(VARCHAR,DATEADD(DAY,-1,GETDATE()),111) --2011/09/21

SELECT CONVERT(VARCHAR,DATEADD(DAY,-1,GETDATE()),107) --Sep 21, 2011

12
2017-07-26 20:00



SI vous voulez utiliser CONVERT et obtenir la même sortie que dans la question originale posée, c'est-à-dire, aaaa-mm-jj alors utilisez CONVERT(varchar(10),[SourceDate as dateTime],121) Même code que les réponses précédentes, mais le code à convertir en aaaa-mm-jj avec des tirets est 121.

Si je peux me lever une seconde, ce type de format n'appartient pas au niveau des données, et c'est pourquoi cela n'a pas été possible sans des "astuces" stupides et lourdes jusqu'à SQL Server 2008 lors de l'introduction des types de données datepart réels. Faire de telles conversions dans le niveau des données est une énorme perte de charge sur votre SGBD, mais plus important encore, la seconde que vous faites quelque chose comme ça, vous avez essentiellement créé des données orphelines en mémoire que je suppose que vous retournerez ensuite à un programme. Vous ne pouvez pas le replacer dans une autre colonne 3NF + ou le comparer à tout ce qui a été typé sans revenir à la version précédente. Tout ce que vous avez fait est d'introduire des points d'échec et de supprimer la référence relationnelle.

Vous devez TOUJOURS aller de l'avant et renvoyer votre type de données dateTime au programme appelant et Dans le niveau PRESENTATION, effectuez les ajustements nécessaires. Dès que vous allez convertir des choses avant de les renvoyer à l'appelant, vous supprimez tout espoir d'intégrité référentielle de l'application. Cela empêcherait une opération UPDATE ou DELETE, à nouveau, à moins que vous n'effectuiez une sorte de réversion manuelle, ce qui expose à nouveau vos données à l'erreur humaine / code / gremlin lorsque cela n'est pas nécessaire.


11
2017-09-22 03:35