Discussion :

[dens19]

Bonjour,

Depuis quelques jours j'essaye d'optimiser des procédures stockées d'une base SQL SERVER 2000, et je m'aperçois que certaines utilisent des variables date comme suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
DECLARE @DateDuJour AS DATETIME
SET @DateDuJour = cast(convert(varchar, GETDATE(),3) as datetime)

Puis cette variable est réutilisée dans le reste de la procédure comme par ex :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT ...
FROM...
WHERE DateReception > @DateDuJour

Or en ayant fait des essais sur une base de test, ou je remplaçais @DateDuJour par une date rentrée manuellement ex : '09/09/09 00:00:00', les requêtes étaient moins gourmandes en ressources. J'ai donc essayé de remplacé la variable par son expression directement dans mes requêtes comme suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT ...
FROM...
WHERE DateReception > cast(convert(varchar, GETDATE(),3) as datetime)

Et effectivement après avoir relancé les procédures concernées, celles-ci ont demandé moins de ressources au serveur (Duration et Read inférieurs sur le profiler).

Ce gain est appréciable mais je n'arrive pas à comprendre ce phénomène, quelqu'un aurait-il une explication ?

Merci d'avance pour vos réponses.

[SQLpro]

Quel est le type de données de la colonne DateReception ? Datetime ou CHAR ???

A +

[dens19]

Bonjour,

il s'agit bien de champs DATETIME dans les tables concernées.

Cdlt.

[mikedavem]

Bonjour,

Quelle version de SQL Server utilisez vous ?

++

[dens19]

je travaille sur des bases SQL SERVER 2000 SP3

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
select @@VERSION
--Microsoft SQL Server  2000 - 8.00.760 (Intel X86)   Dec 17 2002 14:22:05   Copyright (c) 1988-2003 Microsoft Corporation  Enterprise Edition on Windows NT 5.0 (Build 2195: Service Pack 4) 

[SQLpro]

Sachant donc que DateReception est de type DATETIME, il n'y a aucun intérêt, si ce n'est un certains masochisme de caster une date en char puis de la recaster en date !!!! Ce qui est fait ici :

DateReception > cast(convert(varchar, GETDATE(),3) AS datetime)

Il serait plus intelligent d'écire :

DateReception > GETDATE()

Tout simplement.

A +

[dens19]

Je vous assure n'être aucunement masochiste !!!! Je n'ai peut être pas été assez précis dans mon énoncé, ce qui vous induit certainement en erreur. En effet ce code permet de faire des extractions pour la date du jour, par exemple combien de produits ont été reçus depuis ce matin :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
DateReception > cast(convert(varchar, GETDATE(),3) AS datetime) 
-- Equivalent de : DateReception > '15/09/2009 00:00:00'

L'utilisation du code que vous proposez ne me retournera aucun résultat car il prend en compte l'heure actuelle (Equivalent de DateReception > '15/09/2009 13:58:00') :

Il serait plus intelligent d'écire :

Citation:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DateReception > GETDATE()

Je vais quand même essayer de continuer à comprendre pourquoi dans certains cas il est préférable d'utiliser l'expression d'une date directement dans la clause WHERE plutôt qu'en passant par une variable.

A+

[djib29]

Bonjour,

Je peux vous donner un cas dans lequel il est obligatoire de passer par une variable plutôt que par l'expression elle-même.

Lorsque vous utilisez une sous-requête définie dans une fonction, vous ne pouvez pas utiliser GETDATE comme critère de cette sous-requête. Si vous avez besoin de ce critère, vous devez passer cette date en paramètre à la fonction.

L'utilisation d'une variable dans une PS peut s'expliquer si elle a été écrite par quelqu'un qui s'est dit que si ça plante dans une fonction, ça va planter aussi dans une PS...

[elsuket]

Passez donc par une date au format ISO :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT CONVERT(CHAR(8), GETDATE(), 112)

ou encore :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

@++

[Sergejack]

Si DateReception est aussi une date où l'heure (mm, ss, ..) sont à 0, tu peux faire la comparaison :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
DateReception >= DATEADD(dd, -1, GETDATE())

[dens19]

Bonjour à tous,

Merci pour vos réponses.

@Sergejack

DateReception est aussi une date où l'heure (mm, ss, ..) sont à 0

Malheureusement ce n'est pas le cas dans DateReception sont stockées les dates et heures réelles de réceptions.

@Elsuket

Passez donc par une date au format ISO

Je vous remercie je vais essayer de passer toutes mes requêtes impliquant des dates au format ISO.

Je continue par rapport au sujet initiale de ce poste et voici ce que j'observe avec les requêtes suivantes en analysant leur plan d'exécution :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
 
SELECT Numero, DateDeballage
FROM INTER
WHERE DateDeballage >  CONVERT(CHAR(8), GETDATE(), 112)
-- Coût de la requête 0%
GO
SELECT Numero, DateDeballage
FROM INTER
WHERE DateDeballage > CAST(FLOOR(CAST(GETDATE() AS FLOAT)) AS DATETIME)
-- Coût de la requête 25%
GO
SELECT Numero, DateDeballage
FROM INTERV
WHERE DateDeballage > cast(convert(varchar, GETDATE(),3) AS datetime)
-- Coût de la requête 0%
GO
DECLARE @Date1 AS DATETIME;
SELECT @Date1 = CONVERT(CHAR(8), GETDATE(), 112)
SELECT Numero, DateDeballage
FROM INTER
WHERE DateDeballage >  @Date1
-- Coût de la requête 25%
GO
DECLARE @Date2 AS DATETIME;
SELECT @Date2 = CAST(FLOOR(CAST(GETDATE() AS FLOAT)) AS DATETIME)
SELECT Numero, DateDeballage
FROM INTER
WHERE DateDeballage > @Date2
-- Coût de la requête 25%
GO
DECLARE @Date3 AS DATETIME;
SELECT @Date3 = cast(convert(varchar, GETDATE(),3) AS datetime)
SELECT Numero, DateDeballage
FROM INTER
WHERE DateDeballage > @Date3
-- Coût de la requête 25%

Avec DateDeballage de type DATETIME, Numero de type INT.

Je ne comprend pas ces différences sur les plans d'executions de ces requêtes !!!!

A+

[elsuket]

Nous ne pourrons vous aider que si nous disposons des plans de requête ...
Sans eux il est impossible d'aller plus loin ...

@++