Discussion :

[k'n1]

Bonjour a tous,

en fouillant rapidement les possibilites de transact-sql (il y en a quand meme pas mal et on en oublie souvent), je suis tombe sur CASE que je n'avais jusqu'a present jamais utilise.

Or nous avons dans un jeu, une table definissant la liste des "items" possedes par les personnages, avec pour chaque item une ligne de la forme :
- le nom du personnage qui possede
- l'index de l'objet dans l'inventaire du personnage
- le nombre d'utilisations restantes
- le Status de l'objet (0 indisponible, 1 dans l'inventaire...)

On utilise beaucoup ce Status, et donc lorsqu'un joueur utilise un Item, on commence par reduire le nombre d'utilisations restantes par un update, puis si ce nombre devient nul, on fait un nouvel update pour rendre l'objet indisponible (requete de la forme suivante en gros) :

Code :

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

1
2
UPDATE tblObjets SET Restant = Restant - 1 WHERE Perso = @lePerso AND Index=@indexObjet AND Status <> 0
UPDATE tblObjets SET Status = 0 WHERE Restant = 0 Perso = @lePerso AND Index=@indexObjet AND Status <> 0

Mon idee serait donc de reunir tout ca sous une seule requete, qui update les 2 nombres a la fois (si le nombre restant est 1, on sait qu'il finira a 0 apres l'update et donc, on place le status a 0 aussi car l'objet devient inutilisable)

Code :

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

UPDATE tblObjets SET Status = CASE WHEN Restant = 1 THEN 0 ELSE 1 END, Restant = Restant - 1 WHERE Perso = @lePerso AND Index=@indexObjet AND Status <> 0

(J'espere que les exemples de code sont clairs)

Voila donc le concept. Mais mon collegue pense que l'utilisation de CASE ralentit trop le process et serait en realite plus lent que faire les 2 update a la suite, ce dont je ne suis pas du tout certain. Du coup, j'aurais aime savoir ce qui selon vous (par experience si possible ^^) est le plus rapide et efficace : avec ou sans CASE ?

Merci d'avance.

ps: oui je sais, on pourrait supprimer Status et juste utiliser "Restant" pour tester la dispo ou pas de l'item (si different de 0, hop l'item est dispo nickel), mais il se trouve que ce n'est pas possible dans la majorite des cas car status a plus de 2 valeurs dans le cas reel, donc une reelle signification plus que binaire ^_^

[Mercure]

Pour ce que ça vaut, car je ne connais pas le SGBD.

Faire 2 update implique de lire 2 fois la même table.

AMHA, avec le CASE, on doit ralentir légèrement le traitement car le moteur SQL doit effectuer le test, mais en revanche on ne lit qu'une seule fois la table, donc on doit en final gagner du temps.

[k'n1]

C'est aussi ce que je pense. Et c'est un peu ce que la simple logique aurait tendance a dicter, car une fois la ligne lue, le traitement pour le Case ne semble pas tres lourd.

Toutefois mon collegue me soutient que le CASE est relativement lourd a traiter pour le serveur et qu'il vaut mieux l'eviter. C'est aussi possible si ca sort des attributions classiques des fonctions de base internes au serveur, mais pour ca je n'ai pas vraiment de moyen de verifier a part chercher l'experience la ou elle se trouve... ici (enfin il me semble ^_^).

Du coup si quelqu'un a une idee sur cet epineux probleme d'optimisation, je suis preneur.

ps: merci Mercure pour la reponse, je commencais a m'inquieter avec 2 sujets basiques et clairs sans aucune reponse ..

[Mercure]

Je ferais alors un test de perf. sur chaque requête, de nuit pour ne pas perturber les traitements de journée.

Sur un échantillon bien représentatif des données, voire sur l'ensemble de la table, je mesurerais programmatiquement le temps que SQL passe (durée et CPU) à faire les 2 updates puis le temps qu'il passe à faire la requête avec CASE.
Je comparerais ensuite les résultats et je serais fixé.

Ces tests me permettraient ainsi de confirmer l'hypothèse probable du gain de temps auprès de mon collègue ou au contraire de l'infirmer.

[neuropathie]

Selon les best practices et les retours d'expériences que j'ai pu consulter, l'instruction UPDATE est lourde et est à éviter pour les applis web, par contre pour les clients riches elle est utile. donc un UPDATE avec le CASE, je crois que c'est déconseillé

[Rei Angelus]

Je travaille sur SYBASE et j'utilise régulièrement le 'CASE'. Cependant, cela me pose régulièrement des problèmes de temps de traitement qui m'obligent à revenir à des requêtes simples (si possible).

A mon avis les 2 UPDATE seront beaucoup plus rapides que le UPDATE CASE.

Après effectivement, il est judicieux de faire des tests avec ton SGBD et ta base pour en avoir confirmation.

[pcaboche]

Mais mon collegue pense que l'utilisation de CASE ralentit trop le process

Dans la plupart des SGBD, l'utilisation d'un CASE dans une jointure ralentit énormément le temps d'exécution de la requête puisque le SGBD ne peut plus alors se baser sur les index des tables.

Hors d'une jointure, l'exécution est ralentie, mais dans une moindre mesure (2 UPDATE risquent tout de même d'être plus rapides).

Il y a sûrement quelque chose à améliorer dans le modèle pour garantir qu'à tout moment, on ait bien Restant = 0 -> Statut = 0 sans devoir le spécifier pour chaque fois (par une vue, par exemple).

[scornille]

A titre personnel je proscrirais le Case dans un update au même titre qu'un OR dans les trois quart des ordres SQL que je remplace fort volontier par un Union dès que cela est possible ...

D'un point de vue physique le case va empecher d'utiliser les index (sauf si tu fais un index fonction ... auquel cas il faudrait rechercher un peu plus loin) et donc faire un fetch complet de ta table pour faire les update.

Deux updates bien placés sur des clés seront donc beaucoup plus efficaces à mon avis !

[k'n1]

pcaboche, scornille > merci pour vos reponses qui se rejoignent.

Toutefois, je ne comprend pas pourquoi l'utilisation des index est impossible lors de l'utilisation du CASE, tout du moins dans le cas present, ni pourquoi il faudrait faire 2 fetch de la table ?

dans l'exemple cite, la table a un index sur 'Perso' et 'Index' il me semble. On voit que ces 2 elements se trouvent bien dans la clause Where donc pas de soucis. Par contre, on n'utilise pas de case du le 'Status' car il a tendance a pas mal changer, ce qui ralentirait pas mal l'utilisation de la table.

De plus, l'element sur lequel porte le CASE est un element du tuple sur lequel on travail (en l'occurence, toujours unique). A premiere vue, l'operation me parait extremement legere (le tuple a ete lu dans son ensemble (n'est-ce pas ?), vu qu'il a ete trouve par la clause Where, et il a ete trouve rapidement grace aux index).

Je pense qu'il doit me manquer un element de raisonnement, mais je ne vois pas lequel : pour moi il s'agit de l'utilisation classique d'un tuple d'une table (avec ses index) ou l'on verifie simplement un des elements ?

merci d'avance pour vos eclaircissement a cet esprit embrume par le metro matinal... ^_^;

ps: je ne sais pas grand chose sur les vues (on les utilise tres peu ici) ... mais ca m'interesse

[WOLO Laurent]

C'est bien connu dans les règles d'écriture des ordres SQL optimisés :
Il vaut mieux privilégier la logique ensembliste par rapport à la logique procédurale. Plus simplement, Le case serait plus lent que son équivalent sans update.
Vous voulez maintenant vous rassurez : Lancer le plan d'execution de ces deux requêtes et nous allons vous aidez dans l'analyse de ceux-ci.

[Mindiell]

Moi je dirais qu'il vaut mieux approfondir ses connaissances de T-SQL

Voilà une solution avec un seul update et sans case :

Code :

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

1
2
3
4
5
6
7
 
UPDATE tblObjets 
SET Status = SIGN ( Restant - 1 )
, Restant = Restant - 1 
WHERE Perso = @lePerso 
AND Index = @indexObjet 
AND Status <> 0

Et voilà ! La fonction SIGN te retourne 1 en cas de valeur positive et 0 en cas de 0. A priori, le -1 retourné en cas de valeur négative ne sera jamais retourné puisque le Restant minimum est de 0, non ?

Et hop !