この質問は、中規模のインポートに対する SSIS プロジェクトのベスト プラクティスに関する純粋に組織的な質問になります。
そのため、新しいデータで継続的に強化されているソース データベースがあります。次に、ソース データベースのデータを時々ロードするステージング データベースを用意して、ソース データベースのコピーで作業し、現在のシステムを移行できるようにします。私は実際に SSIS Visual Studio プロジェクトを使用してこのデータをインポートしています。
私の問題は、プロジェクトの実際の設計が実際には最適ではないことに気付いたことです。このプロジェクトを SQL Server に移動して、Visual Studio プロジェクトを手動で実行する代わりにインポートをスケジュールできるようにしたいと考えています。つまり、実際のプロジェクトをクリーンアップして最適化する必要があります。
したがって、基本的に、各テーブルのプロセスは単純です。テーブルを切り捨て、ソースから抽出し、宛先にロードします。そして、私は約200のテーブルを持っています。ソース データベースは一度に 1 つの接続しか受け付けないため、抽出を並列化することはできません。では、そのようなプロジェクトをどのように設計しますか?
パッケージごとに 1 つのデータ フローを使用することを推奨している Microsoft のドキュメントを読みましたが、200 の異なるパッケージを管理することは非常に不可能に思えます。一方で、200 個のデータ フローを含む 1 つのパッケージも扱いにくいように見えます...
編集 21/11:
このプロジェクトを開始するときに使用したかった最初のアプローチは、テーブル名のリストを反復処理してテーブルを自動的に抽出することでした。ソース テーブルと宛先テーブルのスキーマ オブジェクト名がすべて同じであるが、ソース データベースと宛先データベースが異なるベンダー (BTrieve と Oracle) のものである場合、これはうまくいく可能性があります。また、命名に関する制限も異なります。たとえば、BTrieve は名前を予約せず、30 文字を超える名前を許可しますが、Oracle はそうではありません。そのため、半自動の列マッピングを使用して 200 のデータ フローを手動で作成することになりました (ほとんどは自動でした)。
宛先データベースの CREATE TABLE クエリを生成するとき、方法論を自動化できる場合に備えて、新しいスキーマ オブジェクト名を生成するメソッドを含む再利用可能な C# ライブラリを作成しました。外部の .NET ライブラリを使用できるパッケージを生成するためのカスタム ツールがあれば、これでうまくいくかもしれません。