Groupe de requêtes SQL par problème de date-heure?

J'ai cette requête SQL:Groupe de requêtes SQL par problème de date-heure?

SELECT DISTINCT 
     [BatchCode] 
     ,SUM([Quantity]) as 'Created' 
     ,[TotalQuantity] 
     ,[Status] 
     ,[Destination] 
     ,[DateCreated] 
     ,[CreatedBy] 
    FROM [FGIS].[dbo].[DropshipPackinglist] 
GROUP BY BatchCode, TotalQuantity, Status, Destination, CreatedBy, ModifiedBy, DateCreated

Le résultat est le suivant:

BatchCode    Created TotalQuantity Status  Destination  DateCreated    CreatedBy 
--------------------------------------------------------------------------------------------------------------- 
0005041007100AHWA11HG 86  86    CREATED MediTelecom S.A. 2010-09-10 00:00:00.000 NULL 
0005041007100AHWA11HGK 19  50    ALLOCATED USA    2010-09-12 07:35:17.000  jy 
0005041007100AHWA11HGK 31  50    ALLOCATED USA    2010-09-12 07:35:20.000  jy

Mon problème est maintenant je ne peux pas DateCreated groupe à cause de cela a différents temps.

Je veux le grouper par date seulement. Exemple: 2010-09-12

Merci et salutations ...

Source

2010-09-12 Crimsonland

Je suppose que cela vaut la peine de poster ce séparément:

L'utilisation de conversions de caractères pour couper les dates de fin (conversion ou conversion en varchar) est plus lente que l'utilisation de DateAdd(Day, DateDiff(Day, 0, DateCreated), 0). J'ai travaillé full script and performance testing results to support this assertion. De plus, veuillez noter que votre liste GROUP BY n'est pas la même que votre liste SELECT, donc quelques ajustements sont nécessaires.

MISE À JOUR

Il semble que les économies CPU pour l'utilisation DateAdd ou conversions varchar, alors que beaucoup relativement, est pas beaucoup tout à fait (quelques fractions de milliseconde par ligne). Cependant, il s'agit toujours d'une différence de performance, et il me semble préférable de sauvegarder tout ce qui est possible.

Source

2010-09-12 05:33:54 ErikE

J'allais faire un post similaire, mais je n'ai aucune information de timing pour le sauvegarder. J'aimerais voir votre quantification de * significativement plus lent *. – Gabe

@Gabe le lundi Je vais essayer de poster quelques informations pour vous. Ce que j'ai trouvé dans les tests passés, c'est qu'il faut beaucoup plus de CPU pour faire des conversions de chaînes plutôt que celles impliquant des maths. C'est un truisme de programmation générale que j'ai trouvé cohérent dans toutes les langues et plateformes. S'il y a deux façons de faire quelque chose et que l'une implique les mathématiques et l'autre implique la conversion de chaînes, la méthode mathématique gagne presque toujours. Parfois, il y a * efficacité * en utilisant des chaînes lorsque les calculs mathématiques sont autrement laborieux, mais pour cette différence directe, les maths gagnent. – ErikE

@Gabe J'ai mis à jour ma réponse avec un lien, s'il vous plaît le voir. – ErikE

Utilisez CAST or CONVERT pour modifier le format de DATETIME sorte que la partie de temps est omise:

SELECT [BatchCode], 
     SUM([Quantity]) as 'Created', 
     [TotalQuantity], 
     [Status], 
     [Destination], 
     CONVERT(VARCHAR(10), [DateCreated], 101) AS datecreated, 
     [CreatedBy] 
    FROM [FGIS].[dbo].[DropshipPackinglist] 
GROUP BY BatchCode, 
     TotalQuantity, 
     Status, 
     Destination, 
     CreatedBy, 
     ModifiedBy, 
     CONVERT(VARCHAR(10), [DateCreated], 101)

Source

2010-09-12 03:42:42

+1, C'était ma conjecture aussi :) – VoodooChild

Je préfère 'CONVERT (VARCHAR (8), [DateCreated], 112)' parce que vous pouvez alors le trier ainsi que le groupe par lui. Bien sûr, sur SQL Server 2008, vous pouvez utiliser 'CONVERT (date, [DateCreated])' et ne pas vous soucier de la conversion de chaîne. – Gabe

@Gabe: Vous êtes encore en train de trier par VARCHAR en utilisant 112 –

Groupe de requêtes SQL par problème de date-heure?

Répondre

Questions connexes