Décomposition d'un job

Bonjour,
J'ai un travail à réaliser et j'ai besoin de votre aide comme toujours ;) .. En fait ils m'ont donnée un job qui n'est pas très compliqué, mais il contient une requête trèèèèès longue.. elle est écrite sur des centaines de lignes et elle utilise plusieurs tables.. Il m'ont demandé de décomposer cette requete en sous jobs.. Bien sur jusqu'à maintenant je ne sais pas comment faire.. Aidez moi si vous avez d'idée et merci d'avance :)

Citation:

---

Envoyé par tulipe_rose

Bonjour,
J'ai un travail à réaliser et j'ai besoin de votre aide comme toujours ;) .. En fait ils m'ont donnée un job qui n'est pas très compliqué, mais il contient une requête trèèèèès longue.. elle est écrite sur des centaines de lignes et elle utilise plusieurs tables.. Il m'ont demandé de décomposer cette requete en sous jobs.. Bien sur jusqu'à maintenant je ne sais pas comment faire.. Aidez moi si vous avez d'idée et merci d'avance :)

---

Je pense que l'idée est de ne plus déléguer les jointures aux SGBD mais à un tMap.


Si tu as ce genre de requête :

Code:

---

1 2 3 4

SELECT TABLE_1.CHAMPS_1, TABLE_1.CHAMPS_2,... TABLE_1.CHAMPS_X , TABLE_2.CHAMPS_1,... TABLE_N.CHAMPS_Y FROM TABLE_1 INNER JOIN TABLE_2 ON (COND_1) ... INNER JOIN TABLE_N.CHAMPS_M (COND_(N-1))

---

Il faut la décomposé en N requête du type dont toutes les sortie se rejoigne dans un tMap

Code:

---

1 2	SELECT TABLE_i.CHAMPS_1, ... SELECT TABLE_i.CHAMPS_x FROM TABLE_i

---

D'abord merci pour votre réponse ;) ,
c'est presque la structure que vous proposiez celle de ma requête mais avec plusieurs "Left Join" au lieu de "Inner Join" avec une clause "Where" à la fin.. Je ne sais pas exactement si ca sera la même chose ou pas..

Pensez a réutiliser les éléments de la clause where dans vos nouvelles requetes afin de limiter la volumétrie que vous ramenez.

Merci beaucoup bstevy :) ,
J'ai juste un petit problème concernant les jointures, est ce que ca sera mieux de les réaliser au niveau d'un tMap ou les laisser directement dans les requetes (càd dans les t..Input).

L'idéee de bstevy est que les conditions de jointure doivent être dans le tMap.
Et les conditions de filtrages sur les tables doivent être dans le requêttes.

Merci supergeoffrey,
Je veux juste savoir quelle est la méthode la plus optimale coté performance.. parce que je souvient que j'ai lu un jour une intervention qui dit que l'utilisation de la jointure directement dans le "t..input" est plus optimal que la réalisation des jointures dans tMap.. est ce que c'est vraiment vrai?

D'une manière général, la base de donnée est prévue pour faire des jointures et a la possibilité d'utiliser des index notament.
Si vous faites vos jointure avec le tmap, il va falloir d'abord trier les données pour pouvoir les joindre, ce qui est extrememnt couteux.

De plus, un inner join aura tendance à limiter la volumétrie que vous ramènerez si les critères de jointure sont correctement effectué. Alors qu'avec le tmap, vous allez devoir tout ramener avant de "filtrer" via la condition de jointure.


Donc oui, c'est plus performant de faire ca dans l'input.
Maintenant, reste à savoir jusqu'ou vous voulez décomposer. Si c'est vraiment tout passer en talend, il faut faire vos jointures en tmap.
Si vous n'avez pas de raison de décomposer en talend, alors restez avec votre grosse requete, ca sera sans doute plus efficace que de passer par talend.

Merci encore une fois pour la clarification, c'est très intéressant..
Bref la requete énorme dont je parle est de la forme

Code:

---

1 2 3 4 5 6 7 8

SELECT Table.champ, REQ_1.CHAMPS_1, REQ_1.CHAMPS_2,... REQ_1.CHAMPS_X , REQ_2.CHAMPS_1,... REQ_N.CHAMPS_Y FROM Left Join REQ_1 ON (COND_1) LEFT JOIN REQ_2 ON (COND_2) ... Left JOIN REQ_N.CHAMPS_M (COND_N)   WHERE ...

---

avec REQ_i est une requete.
est ce que c optimal de mettre dans chaque sous requete:

Code:

---

1 2 3

SELECT REQ_i.champ_1, REQ_i.champ_2... FROM table LEFT Join (Clause de REQ_i) AS REQ_i ON (COND_i) WHERE.....

---

Merci d'avance :)

L'optimal est de faire comme tu le faisait avant.

Après si tu souhaites avoir un compromis entre performance et maintenabilité, tu peux très bien faire un mix des deux.