Discussion :

[rockley]

Bonjour à tous.

J'ai une question assez simple à poser mais je n'ai pas réussi à trouver la réponse pour le moment.
J'ai une table donc la clé est composée de 9 colonnes (je sais c'est énorme).

Je me demande si les deux requêtes suivantes sont équivalentes :

Code :

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

1
2
3
4
5
6
 
Select * From Ma_Table 
Where 
Col1 = XXX
Col2 = YYY
Col7 = ZZZ

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
Select * From Ma_Table 
Where 
Col1 = XXX
Col2 = YYY
Col3 = '%'
Col4 = '%'
Col5 = '%'
Col6 = '%'
Col7 = ZZZ
Col8 = '%'
Col9 = '%'

Est-ce que la deuxième solution respectera mieux le matchCols ou alors c'est pire ?

Merci d'avance pour votre aide.

[escartefigue]

Bonsoir,

Votre requete n'est pas correcte d'un point de vue syntaxique, puisque pour utiliser le wildcard "%" il ne faut pas utiliser l'opérateur égal "=" mais like
Celà étant, même si vous remplacez "=" par "like" pour corriger votre requête, le résultat sera exactement le même puisque like "%" n'est pas sargable

Et comme vous l'avez justement mentionné, 9 colonnes dans un index, c'est rarement judicieux

Et en supplément, si vous êtes soucieux des perfs, remplacez select * par une sélection des colonnes UTILES à votre traitement, vous gagnerez en charge i/O et réseau, et vos résultats seront stables quelque soient les évolutions DDL

[bernard59139]

Bonjour

Mauvaise idée, même en remplacant le "=" par "like".

1. cela risque de consommer des ressources pour rien
2. COL like '%' est toujours vrai

viser à tout prix un "MATCHCOL" sur tout l'index (avec ce genre de méthode) ne servira qu'à perturber les optimisations que db2 fera de toute facon (choix des méthodes d'accès, re-écriture de la requête, ...).
et que, même si un gain est constaté aujourd'hui, ce gain pourrait être annulé demain (changement de stats, de version, de matériel, ..).

@+

[escartefigue]

La solution est peut être de créer un index correspondant à vos critères 1, 2 et 7, sous réserve de vérifier les cardinalités de vos 3 colonnes sur les différentes plates-formes où votre traitement sera exécuté, à commencer par la prod
Profitez en pour vérifier la présence éventuelle d'index inutiles, non discriminants et/ou redondants, surout s'ils sont multiples et multi-colonnes car ils coutent cher en maintenance des chemins d'accès.

Ce serait intéressant que vous communiquiez l'extrait de votre modèle de données (sous forme graphique) pour comprendre ce qui a pu justifier la création de cet index à 9 colonnes !

[rockley]

Bonjour,

Tout d'abord merci pour vos réponse et pardon pour le Like


Le but était de faire un programme de déchargement performant et modulable pour la clause where en fait.

On aurait un fichier de paramétrage qui contiendrait les champs suivant :
Nom-Programme-de-lancement | Nom-Table-Cible-à-décharger | Top-clause-Where-Active | Col-1-Tab-Cible | Col-2-Tab-Cible | ... .


Un programme lirait le fichier et les colonnes contenant des espaces seraient remplacées par des '%', ce qui dans ma tête donnait ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
Select * From Ma_Table 
Where 
Col1 = XXX
Col2 = YYY
Col3 = '%'
Col4 = '%'
Col5 = '%'
Col6 = '%'
Col7 = ZZZ
Col8 = '%'
Col9 = '%'

Dans mon entreprise comme dans beaucoup, on ne peut pas faire de requêtes dynamiques.
Je voulais trouver une solution semi-dynamique.

[bernard59139]

Bonjour

un programme de déchargement performant et modulable

Pourquoi réinventer la poudre? En général, sur les sites MVS, il existe plusieurs outils capable de décharger des tables à partir d'une requête SQL. En vrac DSNTIAUL, UNLOAD (limité et ca n'est pas du vrai SQL), REXX, SYNCSORT, INSYNC, FILEAID, ......

@+

[escartefigue]

Tout à fait d'accord avec Bernard59139, les outils systèmes ou assimilés seront toujours plus performants (surtout pour la phase rechargement) et aussi, ils vous garantissent un bon fonctionnement en cas de montée de version DB2
Des outils comme PLATINUM (partie RC migrator) ou OPTIM permettent en outre d'extraire d'une plate forme, par exemple la prod, pour recharger sur une autre, et ce, en tenant compte des écarts éventuels de DDL

De plus, vous ne pouvez pas garantir la performance de votre outil avec un code qui revient à du SQL dynamique, en effet, selon la table et le where paramétré, vous aurez ou non une requete sargable, et un prédicat plus ou moins filtrant !
Mauvaise solution donc