Discussion :

[holderheck]

Bonjour à tous.

Je viens de commencer l'apprentissage de db2 ( et donc de SQL ).

Et j'ai un peu de mal avec la notion de curseur. Est ce équivalent a la notion de browsing de fichiers (startbr => open, endbr => close et readnext => fetch ?)

merci d'avance pour toute aide/lien/support de cours car je n'ai rien trouvé de satisfaisant sur le net

- Holder -

[fsmrel]

j'ai un peu de mal avec la notion de curseur. Est ce équivalent a la notion de browsing de fichiers (startbr => open, endbr => close et readnext => fetch ?)

En quelque sorte.

En fait, les tables sont les opérandes des opérateurs relationnels : Restrict, Project, Join, Union, etc. Les résultats des opérations sont des tables, en fait des ensembles, et avec SQL, on ne les manipule pas au niveau d'un élément (ou ligne, ou enregistrement si vous préférez).

Hors SQL, quand vous appareillez séquentiellement des fichiers, vous lisez les enregistrements un par un et vous en comparez les arguments pour savoir quel enregistrement de quel fichier traiter en premier, puis écrire un enregistrement sur un fichier en sortie. Vous développez un programme d’au moins cent ou deux-cents lignes à cet effet. Pour réaliser l’équivalent avec SQL, vous écrivez simplement, quelque chose comme : "Fichier1 Join Fichier2 ON argument" et le résultat de cette opération est l’équivalent de votre fichier en sortie. Au passage, vous avez donc remplacé un paquet de lignes de programmation par une seule ligne. Le problème est que votre programme ne sait que faire du résultat qui est un ensemble, puisqu’il traite seulement au niveau de l'enregistrement, qui est un élément.

C’est pour cela qu'a été mis en oeuvre le concept de curseur, pour que vous puissiez considérer le résultat d’un Select ensembliste, quelle que soit la complexité de ce dernier, comme un simple fichier et par Fetch, déplacer un "curseur" sur la ligne suivante de ce résultat et l’exploiter, par exemple afficher ligne par ligne à l’écran de l’utilisateur.

En résumé, SQL vous transmet un sac et le curseur vous permet d’y récupérer les cacahuètes une par une. Au passage, le SGBD s’est coltiné l’algorithme de production du sac, ce qui vous fait gagner bien du temps (et croyez-moi, il est plus fort que nous tous dans ce genre d’exercice, outre que, sous le capot, tout va incomparablement plus vite).

[fremen167]

Petit complément d'info.

Pour reprendre l'analogie de fsmrel, l'OPEN CURSOR constitue le paquet de cacahuètes, ce qui veux dire qu'il exécute le SELECT. Le plus gros du travail est donc fait à ce moment, contrairement au STARTBR qui ne fait "que" positionner un pointeur à un certain endroit du fichier.

En terme de cinématique de traitement, il peut se passer un temps assez long avant que le SGBD retourne un résultat après l'OPEN du curseur.

[fsmrel]

il peut se passer un temps assez long avant que le SGBD retourne un résultat après l'OPEN du curseur.

Concernant la dimension temporelle des choses, il est évident que la constitution du sac peut prendre plus ou moins de temps : entre moins d'une 1 seconde pour des requêtes bien écrites et bien réglées (dans un contexte CICS par exemple, quand le terminaliste n'a pas à attendre plus d'une seconde) et 10 jours dans certains cas de requêtes batch (quotidien) écrites en dépit du bon sens, non soumises à EXPLAIN et non auditées à coups de Detector ou autres outils dédiés (j’ai eu à auditer et "optimiser" ce genre de requêtes dans lesquelles on confond heure et décade quant à la durée).

Mais on s’éloigne de la question posée initialement...

[holderheck]

Milles merci !

Donc si je comprends bien, les jointures de tables et la projection sont faites lors de l' OPEN CURSOR, le FETCH ne réalisant "que" une lecture de ligne de la projection puis un passage a la ligne suivante ( NEXT étant par défaut ) ?

( Si je me trompe de termes, n'hésitez pas à me reprendre )

[Luc Orient]

...
Donc si je comprends bien, les jointures de tables et la projection sont faites lors de l' OPEN CURSOR, le FETCH ne réalisant "que" une lecture de ligne de la projection puis un passage a la ligne suivante ( NEXT étant par défaut ) ?

Ca dépend des cas ...
Dans certains cas il y a matérialisation de la table résultante et dans d'autres cas non ...

[fsmrel]

Donc si je comprends bien, les jointures de tables et la projection sont faites lors de l' OPEN CURSOR, le FETCH ne réalisant "que" une lecture de ligne de la projection puis un passage a la ligne suivante ( NEXT étant par défaut ) ?

A l’ouverture du curseur, le système relationnel exécute l’instruction "SELECT ...", laquelle peut donner lieu à plusieurs opérations relationnelles (Restriction, Projection, Jointure, Union, etc.) qui ont toutes pour opérandes des tables. Par exemple, si la première opération est une jointure naturelle : "Table1 Natural Join Table2", Table1 et Table2 sont les opérandes et la jointure produit une table Table3, de même nature que Table1 et Table2. Par métaphore, disons que Table1 et Table2 se marient et le bébé résultant du mariage est de même nature que ses parents, c'est-à-dire qu’à son tour il pourra procréer. Il est évident que ce qui vaut pour ces êtres mathématiques que sont les tables ne vaut pas pour les fichiers (au moins tant qu'on ne disposera pas d'une algèbre ad-hoc...) Cela dit, tout se passe sous le capot et le SELECT précédent peut donner lieu à 36 opérations, sachant que la toute dernière produira la table finale, celle que vous parcourrez par FETCH, exactement comme le plus banal des fichiers, plein pot.

Considérez la requête ci-dessous (cf. http://www.developpez.net/forums/sho...80&postcount=7)

Code :

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

1
2
3
4
5
6
7
8
9
SELECT   ehpFiness
FROM     tblehpa20071030
WHERE    ehpCodeCategorie = 200
INTERSECT
SELECT  DISTINCT a.ehpFiness
FROM   tblehpa20071030 a,
       tblehpa20071030 b
WHERE  a.ehpFinessJuridique = b.ehpFinessJuridique
AND    a.ehpFiness <> b.ehpFiness

D’un point de vue conceptuel, les opérations sont les suivantes :

Dans un 1er temps (à la détection de l’instruction OPEN CURSOR), le système relationnel prend pour opérande la table répondant au doux nom de tblehpa20071030 et récupère les lignes pour lesquelles on vérifie la condition :

ehpCodeCategorie = 200.

L’opération est une restriction. Appelons W1 la table qui en résulte.

Dans un 2e temps, le système effectue la jointure des tables tblehpa20071030 et tblehpa20071030 (en fait il s’agit d’une auto-jointure). La condition de jointure est donnée par :

WHERE a.ehpFinessJuridique = b.ehpFinessJuridique
AND a.ehpFiness <> b.ehpFiness

Appelons W2 la table qui en résulte.

Dans un 3e temps, le système procède à l’intersection des tables W1 et W2. Appelons W3 la table qui en résulte.

Dans un 4e temps, le système effectue une projection appliquée à la table W3 pour produire une table W4, laquelle a une seule colonne : ehpFiness. C’est notre table résultat.

Dès que cette table ultime sera constituée, le 1er Fetch sera déclenché et à partir de là, elle sera évidemment parcourue très vite, alors qu’entre l’ouverture du curseur et ce 1er Fetch, il aura fallu au système le temps d’effectuer les travaux préliminaires énumérés ci-dessus.

J’ai décrit les opérations selon un point de vue conceptuel, mais dans la réalité, le système peut évidemment prendre des raccourcis, optimiser, réécrire la requête, son but étant de fournir une table résultat le plus rapidement possible et de la façon la plus économique (W1 ne comportera par exemple que le nombre minimum de colonnes nécessaire, à savoir l’unique colonne ehpFiness).

Il se peut aussi que dans la réalité, le système n’ait pas de table résultat à constituer. Considérez en effet la requête :

Code :

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

1
2
Select col1, col2
From T1

Le système partira bille en tête dans le parcours de T1, sans constitution de tables intermédiaires. Time is money.

[holderheck]

Merci pour ces infos, j'ai parfaitement saisie maintenant
Mis à part un détail: qu'est ce qu'une intersection de tables ?
( je connait l'équi-jointure, les jointures externes UNION ALL, FULL/LEFT/RIGHT OUTNER, les jointures internes ... mais pas l'intersection )

En fesant un pas dans l'intégration de requetes SQL dans mon source COBOL, j'ai lu qu'il fallait inclure le SQLCA ... Aucun problèmes, il vas me donner les SQLCODE et compagnie, ça, c'est compris ...

Code :

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

1
2
3
4
5
Dans ma W-S S
EXEC SQL
   INCLUDE SQLCA
END-EXEC.

Ensuite viens le DCLGEN ... Cela doit faire les DECLARE a ma place ?
Comment le coder? Qu'ajoute-il exactement ?
Partons sur un exemple de base simple:

Code :

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

1
2
3
4
5
6
7
 
 CREATE TABLE EMPLOYE
 (
 NUMERO CHAR(4)   NOT NULL,
 NOM      CHAR(30) NOT NULL,
 PRENOM CHAR(15) NOT NULL
 ) IN MY-DATABASE;

Encore merci d'avance pour vos réponses .

-holder-

[Luc Orient]

...
Ensuite vient le DCLGEN ... Cela doit faire les DECLARE a ma place ?
Comment le coder?

Il faut le voir comme une macro COBOL, mais comme il est inséré au niveau du pré-compilateur DB2 alors on va parler d'INCLUDE
Pour le générer il faut utiliser l'outil fourni par DB2, soit sous ISPF soit en batch.

Qu'ajoute-il exactement ?

Deux fonctions pour le DCLGEN :

1) permettre au pré-compilateur de faire un certain nombre de vérifications élémentaires puisque ce dernier n'accède pas au catalogue et n'a pas la vision des tables traitées dans le programme
c'est la partie DECLARE TABLE

2) déclarer les variables hôtes qui sont l'interface aussi bien en lecture qu'en écriture entre les colonnes de la table et le programme lui même. DB2 est très rigoureux sur le type de celles-ci, et, plutôt que les déclarer "à la main" avec de nombreux risques d'erreur, il faut mieux les faire générer par l'outil ad hoc.
c'est la partie déclaration des variables (en général pour du COBOL, mais ça marche aussi pour de l'assembleur, du PL/1 ou du C/C++)

[fsmrel]

Concernant la programmation, il est temps pour vous d'assimiler les ouvrages de référence.

Pour DCLGEN, voyez le lien

http://www-306.ibm.com/software/data...s/v9books.html

où vous récupérerez le fichier .PDF : Application Programming & SQL Guide (SC18-9841-01).

Voyez notamment le chapitre 8 : "Generating declarations for your tables using DCLGEN".

Après cela, vous saurez établir la correspondance entre la structure d'une table au sens SQL et cette structure au sens COBOL.

je connait l'équi-jointure, les jointures externes UNION ALL, FULL/LEFT/RIGHT OUTNER, les jointures internes ... mais pas l'intersection

C'est comme l'intersection de deux ensembles. Voyez le manuel de référence ci-dessus : "Combining result tables from multiple SELECT statements: UNION, EXCEPT, and INTERSECT".

[holderheck]

Il faut le voir comme une macro COBOL, mais comme il est inséré au niveau du pré-compilateur DB2 alors on va parler d'INCLUDE
Pour le générer il faut utiliser l'outil fourni par DB2, soit sous ISPF soit en batch.

Trés bien, je vais voir cela.

Deux fonctions pour le DCLGEN :

1) permettre au pré-compilateur de faire un certain nombre de vérifications élémentaires puisque ce dernier n'accède pas au catalogue et n'a pas la vision des tables traitées dans le programme
c'est la partie DECLARE TABLE
2) déclarer les variables hôtes qui sont l'interface aussi bien en lecture qu'en écriture entre les colonnes de la table et le programme lui même. DB2 est très rigoureux sur le type de celles-ci, et, plutôt que les déclarer "à la main" avec de nombreux risques d'erreur, il faut mieux les faire générer par l'outil ad hoc.
c'est la partie déclaration des variables (en général pour du COBOL, mais ça marche aussi pour de l'assembleur, du PL/1 ou du C/C++)

Trés bien. Je peut donc coder sans problemes si je connais le nom de mes colonnes et leurs formats (une colonne en CHAR(4) seras un PIC X(4) ... etc )

Une autre question qui me vient à l'esprit: vaut-il mieux préparer les ordres SQL en fesant un

Code :

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

1
2
3
4
5
6
7
8
9
10
11
STRING 
'INSERT INTO database (champs) VALUES (''' DELIMITED BY SIZE,
W-VAR1 DELIMITED BY SIZE,
''','''       DELIMITED BY SIZE,
W-VAR2 DELIMITED BY SIZE,
''')' INTO W-ORDRE-SQL

EXEC SQL
   EXECUTE IMMEDIATE :W-ORDRE-SQL
END-EXEC

ou passer les variables dans un INSERT qui se trouve dans les balises SQL ?

PS: Merci pour les liens, je vais potasser cela

[Luc Orient]

... Une autre question qui me vient à l'esprit: vaut-il mieux préparer les ordres SQL en faisant un

Code :

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

1
2
3
4
5
6
7
8
9
10
11
STRING 
'INSERT INTO database (champs) VALUES (''' DELIMITED BY SIZE,
W-VAR1 DELIMITED BY SIZE,
''','''       DELIMITED BY SIZE,
W-VAR2 DELIMITED BY SIZE,
''')' INTO W-ORDRE-SQL

EXEC SQL
   EXECUTE IMMEDIATE :W-ORDRE-SQL
END-EXEC

ou passer les variables dans un INSERT qui se trouve dans les balises SQL ?

Le premier mode de fonctionnement correspond au SQL statique alors que le second correspond au SQL dynamique.

Pour faire simple, mais ça demanderait des développements plus longs, le SQL dynamique est plus souple mais (éventuellement) moins performant alors que c'est l'inverse pour le SQL statique (on s'en serait douté ... ).

Notamment, le SQL statique détermine le chemin d'accès une fois pour toute (au BIND en fait) alors que le SQL dynamique risque de le refaire à chaque exécution.
Par contre, le SQL statique induit une rigidité supplémentaire en introduisant la notion de PLAN et de PACKAGE.

Historiquement, le SQL dynamique a eu une réputation d'inefficacité et de lenteur et de nombreux sites l'interdisent dans leurs normes de développement.

Maintenant, il faut savoir que de nombreux outils (ERP, ODBC, JDBC (?) etc ) privilégient l'utilisation du SQL dynamique et donc, IBM a fait de nombreuses évolutions au fil des versions de DB2 for z/OS pour en améliorer les performances.