これがシナリオです
ソースである csv ファイル用のステージング テーブルが 1 つあります。それを物理ステージング テーブルにロードしています。パッケージの後半で、このステージング テーブルのデータを変換します。新しいデータが必要です (ソースからのデータなので)。
一時テーブルで変換を行う必要がありますか、それともデータフロー タスクを再度使用してステージング テーブルをリロードする必要がありますか
データはそれ以上ではありません [Smile] 100 万未満です
これがシナリオです
ソースである csv ファイル用のステージング テーブルが 1 つあります。それを物理ステージング テーブルにロードしています。パッケージの後半で、このステージング テーブルのデータを変換します。新しいデータが必要です (ソースからのデータなので)。
一時テーブルで変換を行う必要がありますか、それともデータフロー タスクを再度使用してステージング テーブルをリロードする必要がありますか
データはそれ以上ではありません [Smile] 100 万未満です
これには標準的なパターンがあります。
これは、ETLの頭字語の由来です-http ://en.wikipedia.org/wiki/Extract,_transform,_load
主な利点は、ポイント1ではデータをロードするスレッド/ユーザーが1つしかないため、データをすばやく抽出できることです。次に、ステージ2では、他のテーブルをロックせずにデータを操作できます。最後に、データの準備ができたら、ライブテーブルに可能な限り迅速な方法でデータをロードできます。
あなたの2つの最大の(しばしば競合する)懸念は、シンプルさとスピードです。シンプルさは、コードが少なくて済み、必要なデバッグが少なくて済み、データがクリーンであるという確信がはるかに高まるため、優れています。ただし、速度を上げるために単純さを犠牲にしなければならない場合があります。
あなたの場合、ロードするのは数百万行しかないため、毎回ステージングテーブルをリロードして、すべてのロードで同じETLプロセスが使用されるようにすることをお勧めします。これにより、ETLメカニズムのコーディング、保守、および説明が容易になります。
参考までに-SQLServerを使用している場合は、SSISを確認してください。