La requête suivante :

bouffe t-elle plus de ressources que la requête suivante :

 
Merci à vous.

Tu sais que t'as des supers outils DB2 pour répondre à ce genre de question?
Je ne te parlerai pas de l'outil graphique db2cc mais si tu peux l'installer tu en constateras vite les bienfaits ( notament l'option show optimized query, qui peut s'avérer fort utile).

La juste pour l'exemple, on va le faire en ligne de commande.
tu crées une fichier test.sql dans lequel tu mets tes deux requêtes.
Ensuite un petit:

et oooh miracle tu te retrouves avec un beau fichier qui contient tout plein d'infos sur tes deux requêtes.
Tu auras le "estimated cost" qui te donne une bonne idée du cout de ta requête.
Mais egalement à la fin le plan de l'optimizer pour etudier les différences de celui-ci sur tes deux requêtes.

Note enfin que ces deux requêtes seront fortement fonction de l'index sur champ, et qu'un bon coup de db2advis ne ferait pas de mal.

Je suis sous Mainframe. Je n'ai pas tous les droits. Et non je ne connais pas tous ces outils.  
Merci quand même. Je pense que la première est moins coûteuse.

j'ai fait un test sur un base avec 3millions de lignes, le distinct remontait 700K lignes, effectivement la première avait un estimated cost légèrement inférieur (2403 à 2400 ).
 
Maitenant si tu n'as pas tout les droits, c'est qu'il doit y avoir un DBA qui les a non? A lui tu peux pas demander "de l'aide" pour l'optimisation de tes queries?

En fait je fait juste une sorte d'analyse des requêtes qui peuvent consommer en ressources car ce n'est pas moi qui a codé l'application. Donc merci pour ta réponse. Ça veut dire que la requête est bonne.

"bonne"... faut le dire vite.
 
dans l'absolu, toute clause "distinct" signifie qu'il y a un souci.
parfois on ne peut pas faire autrement que de l'utiliser, mais dans tous les cas, il faut chercher par tous les moyens à l'éviter.
 
et pour rappel (juste comme ça en passant), un UNION fait automatiquement des distincts. si on est sûr qu'il n'y a pas de doublons, toujours faire un UNION ALL afin de ne pas multiplier le temps d'exécution par 10

oki merci.

ps : si ton champ fait référence à une autre table, où ces valeurs ne sont pas en doublon, alors une jointure vers cette table, et un count(distinct) sur cette table sera plus rapide
 
voir les tests que j'ai fait sous oracle dans "SGBD" (cf ma signature)

ici : http://forum.hardware.fr/hfr/Progr [...] m#t1447077
 
( quoique je viens de refaire des tests, et c'est pas systématique en fait, ça doit dépendre du nombre de doublons)

oki. En fait dans la requête il y a des filtres via la clause WHERE et deux clauses AND.
 
Je voudrais savoir aussi si ont peut faire un dans le SET de l'ordre SQL UPDATE sans consommer en ressource ? Par exemple :

Pareil pour une insertion ?

 
Encore merci.

oui pour l'update, tu peux incrémenter sa valeur, du coup la syntaxe est champ = champ +1 . Attention à ce que le type soit bien integer/float/decimal
 
Non pour l'insert, ça voudrait strictement rien dire: "Je veux insérer une donnée dans la valeur est sa valeur plus 1".  
En fait j'imagine que tu as besoin de faire un max + 1 sur ton identifiant et que tu galères car tu ne sais pas déclarer ta clé en auto-incrément.
De toute façon l'auto-incrément c'est du caca, mon conseil sert toi d'une sequence.
 
Et puis pense à jeter un oeil sur http://publib.boulder.ibm.com ( la doc officielle db2) tu y trouverais les réponses à 90% de tes questions.

Oui en fait c'est ça. On a une valeur obtenu par un max par exemple. Et pendant l'insertion on met cette valeur+1 dans la table. Ça ne bouffe pas de ressource ?
Merci pour le lien.

insert into matable (champ) values (select max(champ) + 1 from matable)
 
c'est pas très propre, mais ça marche.
si champ est le PK, alors ça va pour ainsi dire ne rien consommer du tout.
 
mais dans tous les cas, anapajari a raison : une séquence c'est ce qu'il y a de mieux.
et encore mieux, un trigger sur ta table qui permte de remplir le champ lorsqu'il n'est pas renseigné, à partir d'une séquence, ou une liste de "trous", etc.)

oki merci pour les infos. Ce n'est pas moi qui ait codé le programme et je n'ai pas la main dessus. Mais c'est intéressant à savoir.  
 
Merci.