2017-10-04 14 views
0

J'ai donc créé un rapport qui exécute essentiellement une instruction DML construite à partir de plusieurs tables volatiles. La façon dont je l'ai construit était que chacune de mes tables temporaires dériverait essentiellement du précédent. Par exemple, dans ma première table, je définis le 'dataset' alors que mes autres tables temporaires définissent mes "exclusions", alors ma dernière table temporaire combine tout cela et l'exécute ensuite dans une requête finale.Création d'une procédure stockée avec plusieurs tables temporaires

Je veux automatiser ce rapport pour extraire des données quotidiennement, mais je ne suis pas sûr de créer une macro ou un sp pour cela. Le plus gros problème avec l'une ou l'autre approche, est comment pourrais-je même être en mesure d'utiliser efficacement chaque table de temp? J'ai pensé à combiner TOUTES mes tables dans une déclaration DML GIANT (1000+ lignes), mais SURELY, sûrement il y a de meilleures options, plus faciles là-bas.

Toute aide est grandement appréciée, merci!

+0

Puisque vous avez mentionné une extraction quotidienne de données, vous n'avez peut-être pas besoin de tables temporaires. Vous pourriez être en mesure d'utiliser des tables de transfert. Ce sont des tables de base de données normales qui ne font pas partie d'un schéma normalisé ou en étoile. Leur but est d'aider avec la partie T d'un processus ETL. Au lieu de créer des tables temporaires tout le temps, vous remplacez simplement le contenu de vos tables de transfert. –

+0

Une autre alternative serait d'utiliser des tables temporaires globales. Ceux-ci sont instanciés lors de l'accès, sont des sessions locales et se matérialisent dans l'espace TEMP d'un utilisateur au lieu de SPOOL. Les définitions de table sont conservées dans le dictionnaire de données. Vous n'avez donc pas besoin de les intégrer dans votre SQL global pour générer le rapport. –

Répondre

0

Sinon, vous pouvez utiliser Common Table Expression (CTE) au lieu des tables temporaires:

WITH cte1 AS 
( 
    SELECT * 
    FROM table_1 
    WHERE 
), cte2 AS 
(
    SELECT... 
    FROM cte2 
    JOIN ... 
    WHERE 
) 
... 
SELECT * 
FROM cte_n; 

Un CTE peut être dépendent d'un précédent ou non, vous pouvez aussi utiliser la récursivité et combiner résultat dans la requête finale.

+0

Après beaucoup de tests, j'ai trouvé que le CTE était le plus applicable. Cependant lors de la création en vue de lui, je ne suis pas sûr de ce que la syntaxe est, le code ci-dessous: CREATE VIEW RÉCURSIVE db.Test_View AS AVEC CTE 3 AS ( SELECT DE CTE 2 ), CTE 2 AS ( SELECT DE CTE 1 REJOIGNEZ ... OÙ ... ), CTE 1 AS ( SELECT DE ... SUR ... OU ... ) SELECT * FROM CTE3 – WhimsicalWhale