Discussion :

[christophe02400]

Bonjour,

j'ai 3 fichiers avec 2 enregistrements contenant le num dans chaque table, je fais la requête suivante :

Code SQL :

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

1
2
3
4
5
6
SELECT * FROM restore/table1 a
inner join restore/table2 b   
on b.num = a.num         
inner join restore/table 3 c   
on c.num = b.num         
where a.num = '10000000'

le résultat :

NUM
10000000
10000000
10000000
10000000
10000000
10000000
10000000
10000000

pourquoi je n'ai pas que 2 lignes en résultat ? sachant que je sélectionne sur 120 colonnes si je fais un group by il faut que je mettes les 120 colonnes. un peu lourd, y a t'il une autre solution ?

MERCI

[escartefigue]

Bonjour,

Ceci n'est pas clair :

j'ai 3 fichiers avec 2 enregistrements contenant le num dans chaque table

Soit il s'agit de fichiers, soit de lignes dans des tables, de quoi s'agit il ici ?


Par ailleurs, la requête est invalide : le slash est un caractère spécial, son utilisation nécessite d'encadrer le nom de l'objet concerné par des guillemets, de plus, faire un SELECT *, en particulier quand il y a des jointures, est contre-performant. Il y a probablement des colonnes dont on n'a pas besoin qui sont transportées inutilement et encombrent donc le réseau, à commencer par la colonne "num" de jointure qu'on a ici 3 fois puisqu'il y a 3 tables
Pensez à utiliser les balises CODE pour encadrer vos requêtes, c'est plus facile à lire (je l'ai corrigé pour vous )

pourquoi je n'ai pas que 2 lignes en résultat ? sachant que je sélectionne sur 120 colonnes si je fais un group by il faut que je mettes les 120 colonnes. un peu lourd, y a t'il une autre solution ?

Parcequ'il y a des relations n-aires entre les tables.


Pour plus d'explications, il faut communiquer le DDL de création des tables et un exemple (extrait) de leur contenu

[christophe02400]

Bonjour,

je suis sur as400 donc j'utilise les / pour les tables et je n'ai pas de DDL sur as400

pour le test du select j'ai mis * sinon je sélectionne des colonnes mais comme j'en ai 120 je ne les ai pas mises dans l'exemple.

[christophe02400]

Pour essayer d'être plus clair, j'ai 3 tables, je veux tous les enregistrement de la table 1 avec des champs en plus qui sont dans la table2 et la table3.

je ne ssais pas si je suis plus clair

[escartefigue]

Le DDL (Data Definition Language) est la sous-partie du langage SQL qui permet de créer, supprimer et modifier les objets (tables, index, fonctions, triggers...) de la base de données. Les scripts de création des tables et index (ordres DROP, CREATE et ALTER) sont du DDL.
C'est ce script qu'il faut nous communiquer ainsi qu'un extrait du contenu de chacune des 3 tables.

Pour le nombre de lignes en résultat, prenons un exemple.
La première table est la table des clients, la deuxième, celle des commandes client et la troisième, celle des lignes de commande client.
Si en moyenne, un client possède 3 commandes et que chaque commande possède en moyenne 10 lignes, une jointure entre ces 3 tables sans regroupement ni clause DISTINCT produira en moyenne 30 lignes par client.

pour le test du select j'ai mis * sinon je sélectionne des colonnes mais comme j'en ai 120 je ne les ai pas mises dans l'exemple.

Il est rare d'avoir besoin d'autant de colonnes. Chaque colonne transportée a un cout réseau au détriment des petits camarades. À vérifier.

[christophe02400]

Merci de m'avoir aiguillé je suis parti sur un DISTINCT j'ai ajouté la ligne ci-dessous :

Code :

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

where a.numadh = (select distinct b.numadh from restore.cartec1) and a.numpag = (select distinct b.numpag from restore.cartec1)

ca fonctionne

Après au niveau des performances ce n'est pas grave c'est un traitement annuel qui prends 30s

MERCI

[Darkzinus]

Bonjour,
Soit il s'agit de fichiers, soit de lignes dans des tables, de quoi s'agit il ici ?

Sur l'AS400 les fichiers (généré par DDS) sont utilisables comme des tables. On peut même croiser des tables format DDL et fichier format DDS dans des requêtes.

[escartefigue]

Il y a plus de 15 ans que je n'ai plus travaillé sur AS/400
Si on peut requêter par SQL sur des fichiers séquentiels, il est très probable que l'AS/400 crée des tables temporaires pour ce besoin, vu quee langage SQL ne s'applique que sur les bases de données relationnelles.
Autre possibilité, la requête SQL est traduite en ordres de lecture des fichiers séquentiels, comme le faisait naguère IDEAL/DATACOM, mais les performances d'accès sont pitoyables dès que le volume à traiter devient important.

[Luc Orient]

Attention, bien des choses ont changé sur cette machine, et notamment autour de la base de données; à noter qu'on ne dit plus AS/400 mais IBM i ...

Allez voir sur le forum la partie dédiée à cette machine ...

[bernard59139]

Bonjour

sans être sur que ce soit valide sur IBM I, je propose

Code :

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

1
2
3
4
5
6
SELECT * FROM restore/table1 a
where exists (select * from restore/table2 b   
              where b.num = a.num)
  and exists (select * from restore/table3 c   
              where  c.num = a.num)
where a.num = '10000000'

les "select distinct" sont une catastrophe dans des sous requêtes.

[escartefigue]

Si on n'a besoin que de la colonne de jointure, on peut aussi utiliser INTERSECT qu'on a rarement l'occasion de mettre en œuvre :

Code SQL :

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

1
2
3
4
5
6
7
8
9
SELECT T1.num 
FROM restore/table1 as T1
intersect 
SELECT T2.num 
FROM restore/table2 as T2
intersect
SELECT T3.num 
FROM restore/table3 as T3
where T1.num = '10000000'

[Darkzinus]

Il y a plus de 15 ans que je n'ai plus travaillé sur AS/400
Si on peut requêter par SQL sur des fichiers séquentiels, il est très probable que l'AS/400 crée des tables temporaires pour ce besoin, vu quee langage SQL ne s'applique que sur les bases de données relationnelles.
Autre possibilité, la requête SQL est traduite en ordres de lecture des fichiers séquentiels, comme le faisait naguère IDEAL/DATACOM, mais les performances d'accès sont pitoyables dès que le volume à traiter devient important.

Ces "fichiers" ont des logiques (qui sont proches d'index DB2) et les performances sont donc tout à fait correctes à condition de les utiliser correctement. Globalement tout ce qui est utilisable sous DB2 en terme de fonctionnalités SQL l'est sur sur ces "fichiers".

[christophe02400]

Merci de vos réponses je vais tester les 2 requêtes ci-dessus et vous fait un retour...

[christophe02400]

la requête avec les where exist fonctionne mais les performances sont catastrophiques. (30s avec inner join, 15mn avec where exist)

la requête avec intersect ne fonctionne pas :

Message : [SQL0512] L'instruction fait référence à des objets dans plusieurs bases de données. Cause . . . . . : L'instruction fait référence aux objets résidant sur plusieurs bases de données. Les objets peuvent être des noms d'objet explicitement qualifiés ou des noms d'alias définis pour référencer une autre base de données. Cette instruction SQL peut faire référence à une seule base de données uniquement. Une instruction CREATE TABLE AS qui effectue une sélection à partir d'une base de données éloignée ne peut pas référencer une table pour laquelle une instruction *FIELDPROC est définie. Elle ne peut pas définit une table de requêtes matérialisée. Si la base de données éloignée ne figure pas sur un serveur IBM i, les clauses INCLUDING ne sont pas admises. Que faire . . . : Assurez-vous que tous les objets utilisés dans l'instruction résident dans la même base de données. Renouvelez votre demande. *L'instruction mise en évidence a échoué, entraînant l'interruption du traitement