Discussion :

[ptit.homm]

Bonjour,

Je souhaiterai juste faire une requête DB2 pour savoir si un champs existe dans la table mais en optimisant la requête.

ex:

Code :

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

1
2
3
4
SELECT 1
FROM TABLE
WHERE VAR_1= "toto"
  AND   VAR_2 = "titi"

je ne veux pas récupérer d'information de la table, juste savoir si le champ est trouvé.

Cependant le compilateur m'oblige a mettre une close INTO.
Existe-il une requête permettant juste de connaitre l'existence d'un champ sans rien récupérer pour éviter la perte de temps des écritures des variables retournés par la requête?

Merci d'avance

[fremen167]

Tu peux essayer comme ça :

Code :

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

1
2
3
4
5
6
 
SELECT DISTINCT (VAR_1)
   INTO :WS-MA-VARIABLE
FROM TABLE
WHERE VAR_1= "toto"
AND VAR_2 = "titi"

Tu n'as qu'à tester le SQL-CODE à +100 / 0 pour avoir ta réponse, et il est probable que DB2 remarquera la contrainte sur VAR_1 en même temps que le DISTINCT pour optimiser son traitement.

[Luc Orient]

VAR_1 et VAR_2 composent la clé primaire ? ou un index unique ?

[ptit.homm]

VAR1 et VAR2 ne font pas parti de la clé primaire.

Pour l'instant ma requête qui ne compile pas est la suivante

Code :

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

1
2
3
4
5
SELECT 1
FRON MATABLE
WHERE VAR1 = :Mavar1
   ANS  VAR2 = :Mavar2
FETCH FIRST 1 ROW ONLY

du coup je suis obligé de mettre la close INTO :

Code :

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

1
2
3
4
5
6
SELECT 1
FRON MATABLE
INTO :Mavarquinesertarien
WHERE VAR1 = :Mavar1
   ANS  VAR2 = :Mavar2
FETCH FIRST 1 ROW ONLY

[xfanx]

je ne suis pas une spécialiste de DB2 mais je ne pense pas qu'il soit possible d'indiquer un ordre SQL dans un programme de type SELECT sans au moins positionner une host variable.

cela dit, ce n'est pas vraiment grave à mon avis d'en mettre une. Le temps consommé est surtout celui permettant à DB2 d'exécuter ta requete et ce n'est pas la valorisation ou non de la host variable qui fera la difference sur le temps d'exécution.

[Cirdeco]

Si var1 et var2 ne font pas parti de ta clé primaire et si tu ne passes pas pas spuffy, ton select plantera il me semble en renvoyant un sqlcode égal à -811.

Par spuffy tu n'est pas obligé de passer par des host variables mais avec un programme tu es obligé. Pour moi, soit tu passes par un curseur pour éviter un plantage ou tu réalises un count ressemblant a cela.

Code :

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

1
2
3
4
5
 SELECT COUNT(*)
   INTO WS-VAR
   FRON MATABLE
WHERE VAR1 = :Mavar1
   ANS  VAR2 = :Mavar2

Le fetch est plus performant il me semble tout dépend si tu es à l'aise avec les curseurs ou pas.

Voila, j'espere ne pas avoir dit n'importe quoi et que cela pourra t'aider.

[fremen167]

Le SELECT COUNT n'est pas une bonne idée, surtout si VAR1 et VAR2 ne sont pas dans la clé, car il oblige à parcourir toute la table.

ptit.homm, as-tu essayé ma requête ? Personne n'a réagi à ma proposition, ai-je dit une énormité ?

[Cirdeco]

Le SELECT COUNT n'est pas une bonne idée, surtout si VAR1 et VAR2 ne sont pas dans la clé, car il oblige à parcourir toute la table.

ptit.homm, as-tu essayé ma requête ? Personne n'a réagi à ma proposition, ai-je dit une énormité ?

Pour moi, si ta requête me semble bonne tout comme la mienne mais après cela se joue au niveau des performances et là tu me bats .

Mais une règle que l'on m'as appris dans le cas d'une requête sur des variables ne représentant pas la clé primaire et qui niveau performance marche très bien c'est l'utilisation d'un curseur. Il me semble que dans ce cas précis c'est ce qui est le plus performant, non???

[fremen167]

Pour moi, les deux requêtes sont équivalentes en termes de performances :

• si les valeurs recherchées de VAR1 et VAR2 existent dans la table, DB2 s'arrêtera à la première ligne trouvée (en tous cas, pour le FETCH, c'est sûr) ;
• mais dans le cas contraire, il va balayer toute la table !

[xfanx]

En fait non.
lors d'un Fetch, DB2 aura construit toute sa table résultante avant le 1er fetch, lors de l'OPEN CURSOR.
Donc du point de vu I/O que ce soit un Count(*) ou un OPEN/Fetch; la performance est sensiblement la même.

[Luc Orient]

En fait non.
lors d'un Fetch, DB2 aura construit toute sa table résultante avant le 1er fetch, lors de l'OPEN CURSOR.

Non. Ca dépend des requêtes. DB2 peut très bien décider ne pas matérialiser la table résultante.

La requête avec FETCH FIRST 1 ROW est pour moi la façon la plus performante de répondre à la question posée.

Si VAR1 et VAR2 font partie d'un index on a, bien sûr, la possibilité d'une bien meilleure performance.

[fremen167]

Non. Ca dépend des requêtes. DB2 peut très bien décider ne pas matérialiser la table résutante.

La requête avec FETCH FIRST 1 ROW est pour moi la façon la plus performante de répondre à la question posée.

Si VAR1 et VAR2 font partie d'un index on a, bien sûr, la possibilité d'une bien meilleure performance.

+1

DB2 est obligé de créer la table complète dans certains cas, par exemple quand il y a une clause ORDER BY qui ne peut être satisfaite à l'aide d'un index. Mais ici, il serait très surprenant qu'il le fasse.

[ptit.homm]

Merci pour toutes les réponses que vous m'avez apportées.

Pour finir la solution choisie est la suivante :

Code :

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

1
2
3
4
5
6
SELECT 1
FRON MATABLE
INTO :Mavarquinesertarien
WHERE VAR1 = :Mavar1
   ANS  VAR2 = :Mavar2
FETCH FIRST 1 ROW ONLY

Avec le select 1 , ce nul de DB2 doit avoir une Host-variable tout ca pour stocker le "1" dans la variable.
Donc si une occurence est trouvé Mavarquinesertarien = 1

Je pense que la solution d'un fetch n'est pas tres performante et je pense inutile dans mon cas, un Select suffit je pense.
Le FETCH FIRST 1 ROW ONLY permet a DB2 de s'arreter dès qu'il a trouvé une occurence. Contrairement au COUNTet au DISTINCT qui va parcourir toute la table.

Mes variables de mon WHERE ne sont pas des clés de la table, j'ai fait ajouté un index sur la table pour gagner un peu en performance.

Merci beaucoup pour toute vos réponses, car il n'est vraiment pas facile de trouver de l'aide en COBOL sur le net.

Bonne journée.

[fremen167]

Le FETCH FIRST 1 ROW ONLY permet a DB2 de s'arreter dès qu'il a trouvé une occurence. Contrairement au COUNTet au DISTINCT qui va parcourir toute la table.

Pour le DISTINCT, dans ce cas précis (la valeur présente dans le SELECT est contrainte par la clause WHERE), cela reste à vérifier