Discussion :

[SuperWaza]

Bonjour,
existerait-il une doc sur les bonnes pratiques à suivre dans le cadre du développements SQL sur des bases de données type DB2 Z/OS ?

Exemple ...
Ne pas trop utiliser les fonctions de convertions
Bien cibler les données
etc ....

[bernard59139]

Bonjour

je pense qu'il n'y a pas de doc spécifique.

Ma bible est "Application Programming and SQL Guide", surtout les chapitres "tuning your query" et "explain".

selon mes activités, je complete avec les redbooks (redbooks.ibm.com).

bonne lecture

[Cirdeco]

Bonjour,

il me semble qu'en haut de cette page, caché entre plusieurs boutons, il y en a qui sont appellés tutoriel DB2 et tutoriel SQL.

N'as tu pas trouvé les informations que tu recherche dans ces tuto ?

Cordialement,

[pdz74]

Bonsoir,

Le sujet est vaste, c'est le moins que l'on puisse dire. Qui dit bonne pratique du langage SQL, commence par dire bonne modélisation. En effet, un modèle de données non orienté relationnel, débouchera quasi à coup sur sur des problèmes de perf par exemple. Ex typique : un logiciel écrit à l'oirigine en vsam. Pour faire bien, on passe à DB2 en faisant du copier/coller des anciens fichiers vsam en table DB2. C'est une hérésie et pourtant de nombreux logiciles sont ainsi !

Ensuite, toute la partie système : bon paramétrage de la ZPARM, optimisation des différents espace mémoire (bufferpool, edmpool, ...).

Enfin les accès aux données : il existe des formations d'une semaine pour répondre à ta question. En quelques lignes dans un message, c'est donc mission impossible. Ceci dit, les docs DB2 cités sont pleines de bonnes idées. Restent à les trouver dans des docs de 1000 pages auxquelles on peut ajouter tout de qui concerne les utilitaires, sql references, ...

Très honnêtement, il est préférable de commencer par une bonne formation qui te donnera les grandes orientations.

Bonne utilisation de DB2.

[Luc Orient]

... existerait-il une doc sur les bonnes pratiques à suivre dans le cadre du développements SQL sur des bases de données type DB2 Z/OS ?

Normalement, il devrait exister de la documentation sur les normes et standards en vigueur sur votre site, non ?

[fsmrel]

Bonsoir,

un logiciel écrit à l'oirigine en vsam. Pour faire bien, on passe à DB2 en faisant du copier/coller des anciens fichiers vsam en table DB2. C'est une hérésie

Et si au niveau logique, les structures des données hébergées par les fichiers VSAM (ou BDAM, etc.) respectent l’intégrité d’entité (clés NOT NULL) et la cinquième forme normale ? Il restera à nommer et typer les attributs des tables, définir les clés candidates, établir les contraintes d’intégrité référentielle. Dans ces conditions, quels défauts présenteraient ces tables du point de vue structurel vis-à-vis de la théorie relationnelle ? Et si par-dessus le marché, le MCD (ou le diagramme de classes) obtenu par rétroconception de l’ensemble des tables obtenu est irréprochable ?

[Peut-êtreUneRéponse]

Normalement, il devrait exister de la documentation sur les normes et standards en vigueur sur votre site, non ?

Complètement de l'avis de Luc Orient, contact le support dev ou bien l'équipe DBA qui seront sans doute ravis que tu te préoccupes de cette problématique.

.

[SuperWaza]

Contacter l'équipe DBA, déjà fait mais pas de réponses concrètes ... voila pq ? je me tourne vers ce site

[Peut-êtreUneRéponse]

Bon je me lance, en vrac (merci de me reprendre si grosses bêtises de ma part) :

• Pas de SELECT *, nommer toutes les colonnes souhaitées et seulement celles dont vous avez besoin
• Penser à la gestion des COMMIT en batch
• Tester systématiquement le SQLCODE après tout ordre SQL. En cas de code SQL négatif, arrêter le traitement après avoir effectué un display de la SQLCA via DSNTIAR (ou GET DIAGNOSTICS)
• Dans le cas d'un index multi colonnes, penser à indiquer la 1ere colonne de l'index dans la WHERE condition même si la valeur est unique car l'index ne serait pas utilisé (Oracle, pas sûr pour DB2)
• Les requêtes doivent avoir un prédicat indexable et filtrant
• Préférer LIKE à SUBSTR
• Préférer NOT EXISTS à NOT IN
• Préférer BETWEEN à >= and <=
• INSERT par tableau multi-rows (à partire de v8) : éviter en TP, en batch se limiter à une centaine d'insertion
• Préférer les CTE common table expression (WITH XXX AS (SELECT...)) aux INNER JOIN (maintenance amélioré car meilleure lisibilité)
• En cas de jointure de 2 tables indexées, mettre la moins volumineuse en dernier (La 2eme table, directrice est parcourue séquentiellement) (Oracle)

[SuperWaza]

Très interessant ... tu trouves cela ou ? Es-ce par expérience ?

[Luc Orient]

...
Dans le cas d'un index multi colonnes, penser à indiquer la 1ere colonne de l'index dans la WHERE condition même si la valeur est unique car l'index ne serait pas utilisé (Oracle, pas sûr pour DB2)

Si la première colonne d'un index n'a qu'une valeur (FULLKEYCARDF = 1), cette colonne n'est pas du tout discriminante et on peut vraiment de poser la question de ce choix.

Voir aussi ce fil :
DB2 z/OS Index et performances

Par contre, dans le cas où l'on souhaite qu'une requête soit indexé via un index multi-colonnes, je confirme la nécessité de valoriser dans le prédicat de celle-ci le maximum de colonnes, et que la valorisation doit toujours se faire dans l'ordre des colonnes de l'index.
En d'autres mots, si la valorisation est partielle, les colonnes manquantes doivent être à la fin plutôt qu'au début de l'index.
Cette règle générale s'applique bien évidemment en particulier pour la première colonne de l'index.