したがって、基本的に複数の揮発性テーブルから構成されるDML文を実行するレポートを作成しました。私が作成した方法は、私の一時テーブルのそれぞれが基本的に以前のものから派生するということでした。たとえば、最初のテーブルでは「データセット」を定義し、「除外」を定義する他の一時テーブルでは、最後の2つのテンポラリテーブルがすべて結合され、最後のクエリで実行されます。複数の一時テーブルを持つストアドプロシージャの作成
毎日データを取り込むようにこのレポートを自動化したいのですが、マクロまたはSPを作成するかどうかはわかりません。いずれのアプローチでも大きな問題は、どのようにして各テンポラリテーブルを効果的に活用できるかです。私はすべてのテーブルをGIANT（1000+行）のDMLステートメントに組み合わせることを考えましたが、確かにそこにはより良い、簡単なオプションがあります。
ご協力いただきありがとうございます。
また、あなたが代わりに一時テーブルのCommon Table Expression (CTE)を使用することができます：CTEは、前の1かに依存することができます
WITH cte1 AS
(
SELECT *
FROM table_1
WHERE
), cte2 AS
(
SELECT...
FROM cte2
JOIN ...
WHERE
)
...
SELECT *
FROM cte_n;
一つ、あなたはまた、再帰を使用して、最終的なクエリで結果を組み合わせることができます。
多くのテストの結果、CTEが最も適用可能であることがわかりました。それからビューを作成するしかしとき、私は構文が何であるかわからないんだけど、以下のコード： CREATE RECURSIVE VIEW db.Test_View AS 、 CTE 2（ は、CTE 2 FROM を選択）などCTE 3 WITH AS（ が... ... を登録しようCTE 1 FROM を選択）、 AS CTE 1（ が... がON JOINを... FROM ... を を選択）を選択 * CTE3から – WhimsicalWhale
毎日のデータプルについて言及したので、一時表は必要ありません。ステージングテーブルを使用できる可能性があります。これらは、正規化スキーマまたはスタースキーマの一部ではない通常のデータベース表です。その目的は、ETLプロセスのT部分を支援することです。一時テーブルを常に作成するのではなく、ステージングテーブルの内容を置き換えるだけです。 –
また、グローバル一時表を使用する方法もあります。これらはアクセス時にインスタンス化され、セッションローカルであり、SPOOLの代わりにユーザーのTEMP空間に具体化されます。表定義はデータ・ディクショナリに保持されているため、レポートを作成するために全体のSQLに埋め込む必要はありません。 –