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!
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. –
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. –