Discussion :

[devvanjier]

Salut à tout le monde,
Je viens d'écrire une requête pour un collègue et j'ai beaucoup utilisé le CASE WHEN avec au moins quatre (04) choix dans chaque structure. Je me suis alors posé la question si cela n'était pas contraire aux bonne pratiques de SQL SERVER.
Merci de m'éclairer svp.

[aieeeuuuuu]

Bonjour,

A priori non.
mais... en voyant la requête, on pourrait sans doute en dire plus...

[devvanjier]

Bonsoir à tous,
ci-dessous un bout de la requête avec les structures

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
 
GO
SELECT DISTINCT
'''' + CONVERT(VARCHAR(40),ct.ContactId)+''',' AS IdContact,
crt.ContractId, 
crt.jfa_Referencecontrat AS [Ref. Contrat],
brt.gs2e_adrtechnique AS [Adresse technique],
ct.FullName,
CASE 
WHEN crt.jfa_StatutSAPHIR = 1 THEN 'Contrat actif'
WHEN crt.jfa_StatutSAPHIR = 7 THEN 'Contrat à résilier'
WHEN crt.jfa_StatutSAPHIR = 4 THEN 'Contrat résilié'
END AS [Statut contrat], 
 
CASE 
WHEN it.gs2e_Typeinterventionsgo = 1 THEN 'Activité de repose'
WHEN it.gs2e_Typeinterventionsgo = 10 THEN 'Activité de coupure'
WHEN it.gs2e_Typeinterventionsgo = 11 THEN 'Activité de rétablissement'
WHEN it.gs2e_Typeinterventionsgo = 16 THEN 'Activité de dépose'
END AS [Type activité],
 
CASE 
WHEN sca.jfa_StatutSAPHIR = 1 THEN 'A planifier'
WHEN sca.jfa_StatutSAPHIR = 3 THEN 'Pour saisie du CRI'
WHEN sca.jfa_StatutSAPHIR = 5 THEN 'Réalisé'
END AS [Statut activité],
 
lot.gs2e_name AS [Nom du lot],
FORMAT(lot.CreatedOn,'dd/mm/yyyy') AS [Date création lot],
'''' +CONVERT(VARCHAR(40),sca.ActivityId)+''',' AS IdActivité
FROM Contact ct WITH (NOLOCK)
INNER JOIN ContractBase crt WITH (NOLOCK) ON crt.CustomerId = ct.ContactId

J'espère que cela suffit.
Bon après-midi à tous

[SQLpro]

Vous utilisez le cas généralisé alors que celui-ci n'est pas optimisable et que vous pouvez utiliser le case valué. Récrivez comme ceci :

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
SELECT DISTINCT
'''' + CONVERT(VARCHAR(40),ct.ContactId)+''',' AS IdContact,
crt.ContractId, 
crt.jfa_Referencecontrat AS [Ref. Contrat],
brt.gs2e_adrtechnique AS [Adresse technique],
ct.FullName,
CASE crt.jfa_StatutSAPHIR
WHEN 1 THEN 'Contrat actif'
WHEN 7 THEN 'Contrat à résilier'
WHEN 4 THEN 'Contrat résilié'
END AS [Statut contrat], 
 
CASE it.gs2e_Typeinterventionsgo
WHEN 1 THEN 'Activité de repose'
WHEN 10 THEN 'Activité de coupure'
WHEN 11 THEN 'Activité de rétablissement'
WHEN 16 THEN 'Activité de dépose'
END AS [Type activité],
 
CASE sca.jfa_StatutSAPHIR
WHEN 1 THEN 'A planifier'
WHEN 3 THEN 'Pour saisie du CRI'
WHEN 5 THEN 'Réalisé'
END AS [Statut activité],

De plus vous pourriez mettre des tables de référence et faire des jointures, surtout s'il y a beaucoup de lignes !

je passe aussi sur le NOLOCK qui est une véritable connerie en production et donne des valeurs fausses !

A +

[devvanjier]

Bonjour,
Merci pour cette précision. Comme vous abordez le sujet du NOLOCK effectivement j'ai constaté certaines fois en production on avait des valeurs totalement erronées, mais je n'arrivais pas à me l'expliquer. J'ai maintenant une piste et je vais creuser du côté du NOLOCK que nous utilisons beaucoup en production sur une base de données CRM 2013. Aussi par quoi pouvons nous remplacer le NOLOCK ??
Merci d'avance

[SQLpro]

Bonjour,
Merci pour cette précision. Comme vous abordez le sujet du NOLOCK effectivement j'ai constaté certaines fois en production on avait des valeurs totalement erronées, mais je n'arrivais pas à me l'expliquer. J'ai maintenant une piste et je vais creuser du côté du NOLOCK que nous utilisons beaucoup en production sur une base de données CRM 2013. Aussi par quoi pouvons nous remplacer le NOLOCK ??
Merci d'avance

Par le niveau d'isolation SNAPSHOT par exemple.

NOLOCK ne signifie pas "je ne pose pas de verrou", mais plus précisément : "j'ignore qu'il y a des verrous et je lit ce que je peut" (ceci est plus connu dans la littérature professionnelle sous le nom de lecture dans le chaos...). Vous pouvez donc lire plusieurs fois les mêmes données ou encore ne pas lire certaines.

SNAPSHOT fait du verrouillage optimiste pour les lectures. Par défaut SQL Server fait du verrouillage pessimiste, c'est à dire que les lectures posent des verrous qui permettent d'autres lectures concurrentes, mais empêchent les écritures des autres utilisateurs. Le verrouillage optimiste (donc via SNAPSHOT) fait une copie (si besoin) des données avant de permettre leurs lectures. Comme vous travaillez sur une copie, les utilisateurs concurrent peuvent modifier les vraies ligne sans que cela vous concerne. Bien entendu il peut toujours y avoir des conflits, mais cela réduit considérablement le nombre de verrous bloquants tout en gardant l'intégrité et la consistante de la base, ce qui n'est pas du tout le cas du NOLOCK.

Alors, à quoi sert le NOLOCK ? Cela peut servir pour certains cas ou l'on désire des résultats dont on se fout de l'intégrité ou de la précision. Souveznt dans le domaine de la statistique.
par exemple si vous voulez savoir combien les français ont d'enfant par foyer est scrutez donc, pour cela une table de 60 millions de lignes (population française), je ne suis pas sûr que sur un camembert représentant la chose on fasse la distinction des quelques pixels de la 6^e décimale du résultat !
On utilise d'ailleurs très souvent le NOLOCK pour des tâches d'administration systèmes dans SQL Server afin d'éviter tout blocage au risque de perdre quelques lignes, ce qui n'a pas toujours une importance capitale lorsque l'on veut remonter quelques lignes concernant les 20% de requêtes les moins performantes !

Mais alors, le SNAPSHOT fait la même chose en mieux ? Oui et non... Certes il permet de garantir l'intégrité, la consistance, etc... mais son mécanisme est plus lourd (un peu moins rapide) et consomme des ressources pour générer les copies (SNAPSHOT). Rassurez-vous il est assez malin pour ne faire ces copies qui s'il a besoin de les faire... En d'autres termes si aucun utilisateur concurrent veut faire des modif sur le jeu de lignes que vous manipulez en mode SNAPSHOT, aucune copie ne sera générée. Mais si, lorsque vous avez démarré une lecture en mode SNAPSHOT, un utilisateur concurrent veut modifier des lignes, et bien la copie sera réalisée au cours de votre lecture sans que vous vous en aperceviez... En quelque sorte le système fonctionne à l'envers... Bien évidemment il faut un espace de stockage pour ces copies et c'est la base tempdb qui s'y colle. Il faut donc, la dimensionner correctement...
Tiens, à nouveau un travail de DBA !

A +

Pièce jointe 393910

[devvanjier]

Merci d'avoir pris le temps de me répondre et surtout pour cette précision.
A+