Discussion :

[sbouvetJD]

Bonsoir,

Quelle différence / appréciation / préconisation pour récupérer une partie de date ? Si par exemple je souhaite connaître la liste des clients nés en mai ou septembre, vaut-il mieux

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
-- 1
SELECT *
FROM CLIENTS
WHERE MONTH(DD_NAISS) IN (5, 9)
-- 2
SELECT *
FROM CLIENTS
WHERE DATEPART(month, DD_NAISS) IN (5, 9)
-- 3, 4
SELECT *
FROM CLIENTS
WHERE DATEPART(month, DD_NAISS)  = 5
UNION
SELECT *
FROM CLIENTS
WHERE DATEPART(month, DD_NAISS) = 9

Y a-t-il encore mieux ?

[SQLpro]

Étudiez les différents plans de requête (menu : "Requête" : "Afficher le plan d'estimé").

A +

[sbouvetJD]

Query 1 : 25.09 %
Query 2 : 25.09 %
Query 3 : 49.81 %

donc apparemment DATEPART et MONTH se valent ?

[Waldar]

Attention, pour votre requête numéro trois il faut utiliser UNION ALL, UNION effectue par défaut un dédoublonnage, qui s’avérera inutile puisque une même personne ne peut pas être née en mai et en septembre, et ceci à un impact sur le plan d'exécution.
Au final les trois requêtes vont se valoir.

De manière générale je vous encourage à utiliser plutôt DATEPART, car c'est la fonction générique pour extraire une partie de date : avec les semaine, les jours, les années, les heures et cetera vous utiliserez toujours la même fonction.

[aieeeuuuuu]

Au final les trois requêtes vont se valoir.

je pense que malgré tout, la requête avec UNION ALL engendrera deux scans, alors que les autres n'en feront qu'un.

Y a-t-il encore mieux ?

Évitez le SELECT *, spécifiez les colonnes dont vous avez besoin

Par ailleurs, vous pourriez créer une colonne calculée persistante indiquant le mois de naissance, et créer un index dessus. Il faut cependant voir si c'est pertinent dans votre cas. (Si votre requête est exécutée une fois par mois par un robot pour souhaiter par mail un joyeux anniversaire à vos clients, c'est très discutable. Si en revanche vous mettez sur la page d’accueil de votre intranet la liste des clients dont c'est l’anniversaire dans le mois, ça peut être utile, surtout que je ne crois pas trop m'avancer en supposant que vos clients ne changent que très rarement de date de naissance)

donc apparemment DATEPART et MONTH se valent ?

oui, elles sont strictement équivalentes.
En fait, lors de l'analyse de la requête, SQL server traduit le MONTH(x) en DATEPART(MONTH,x)

[sbouvetJD]

Évitez le SELECT *, spécifiez les colonnes dont vous avez besoin

Par ailleurs, vous pourriez créer une colonne calculée persistante indiquant le mois de naissance, et créer un index dessus. Il faut cependant voir si c'est pertinent dans votre cas. (Si votre requête est exécutée une fois par mois par un robot pour souhaiter par mail un joyeux anniversaire à vos clients, c'est très discutable. Si en revanche vous mettez sur la page d’accueil de votre intranet la liste des clients dont c'est l’anniversaire dans le mois, ça peut être utile, surtout que je ne crois pas trop m'avancer en supposant que vos clients ne changent que très rarement de date de naissance)

Effectivement, nous n'employons pas le "SELECT *" je l'avais mis ici simplement en terme de simplification de requête. Quant à la colonne calculée, justement nous avons un système mensualisé de notification d'anniversaire et un autre outil utilisé ponctuellement avec requêtage de ce type.

Merci à tous.