0

別の SQL サーバー データベースに完全に存在する 2 つのアプリケーションをマージするという課題があります。各データベースは、5,000,000 の範囲の連続した整数である独自の内部データベース ID を維持します。標準 API 経由でデータをインポートするツールを使用しています。

私が直面している主な課題は、データセットがマージされた後の親子関係の参照整合性に関係しています。例については、下の表を参照してください。各アプリケーションのデータ構造は同じですが、データは一意です。すべてのデータを 1 つのシステムに常駐させたいと考えています。

1 つの例は、複数のタスクを持つプロジェクト オブジェクトであり、各タスクには複数のリソースを割り当てることができます。括弧内は、各オブジェクト タイプの内部データベース シーケンス ID (主キー) です。各プロジェクトは一意であり、各タスクはプロジェクトごとに一意ですが、同じリソースを複数のプロジェクトおよびタスクに割り当てることができます。

システム 0

Project 1 (PROJECT ID 5000001)                  
    Task A ( TASK ID 5000001)                   
        Resource X (RESOURCE ID 5000001)            
        Resource Y (RESOURCE ID 5000002)        
    Task B ( TASK ID 5000002)                   
        Resource Y (RESOURCE ID 5000002)            
        Resource Z (RESOURCE ID 5000003)            

Project 2 (PROJECT ID 5000002)                  
    Task A (TASK ID 5000003)                    
        Resource Z (RESOURCE ID 5000003)            
    Task B (TASK ID 5000003)                    
        Resource X (RESOURCE ID 5000001)

システム1

Project 3 (PROJECT ID 5000001)  
    Task C ( TASK ID 5000001)   
        Resource F (RESOURCE ID 5000001)    
        Resource G (RESOURCE ID 5000002)    
    Task D ( TASK ID 5000002)   
        Resource G (RESOURCE ID 5000002)    
        Resource H (RESOURCE ID 5000003)    

Project 4 (PROJECT ID 5000002)  
    Task A (TASK ID 5000003)    
        Resource H (RESOURCE ID 5000003)    
    Task B (TASK ID 5000004)    
        Resource F (RESOURCE ID 5000001)

上記のデータから、システム 0 からプロジェクト 1 をマージすると、既存のプロジェクト ID 5000001 が原因で、ターゲット システム 1 のプロジェクト 3 がどのように上書きされるかがわかります。

私の質問は、参照整合性を維持しながらデータをマージする方法ですか? 私が最初に考えたのは、オブジェクトごとに両方のシステムからの両方のデータ セットを結合し、インポートされるレコードを何らかの方法で更新し、新しい内部 ID を保存し、その新しい参照 ID を関連オブジェクトにカスケードするビューを作成することです。より簡単なアプローチはありますか？

これを自動化できるツールはありますか?

4

3 に答える 3

1

Redgate sql データ比較ツールを使用することをお勧めします。無料ではありませんが、それだけの価値があります。ここにそのリンクがあります

于 2013-06-12T19:05:56.323 に答える
0

2つしかないので、1つのオプションは「ネガティブになる」ことです。

int または big int とサロゲート キーのデータ型を使用しており、かつ (1,1) (または同様の) ですべてのシードを開始した場合は、1 つのデータベースのサロゲートを否定できます。

ただし、">0" をチェックするクライアント コードを使用している可能性があります。

実際の範囲は次のとおりです。

MySurrogateKey  int IDENTITY (-2147483648,1)

(正に 2147483648 )...1 (または 0) から開始する必要はありません。

于 2013-06-12T18:59:17.513 に答える
0

これは特に簡単ではありませんが、1 つの (大規模な) ストアド プロシージャですべての操作を実行できます。

私がすること (個人的なアプローチ、他の人は別の方法で行う可能性があります) は、既存のデータベースのそれぞれと、最初は「空」である 3 つの SQL Server インスタンスを作成することです。最初のデータベースからすべてのテーブルを読み取り、それらを 3 番目のデータベースに書き込み、ID フィールドに 10,000,000 (1000 万) を追加するストアド プロシージャを作成します。この 5000001 は 15000001 になります。ストアド プロシージャの後続の手順では、これらの PK を指すすべての外部キーを更新して、それぞれに 10,000,000 を追加します。

同様のプロセスに従って、2 番目のプロジェクト データベースの ID フィールドに 20,000,000 を追加し、新しく番号を付け直したテーブルをデータベース 4 に書き出します。次に、前のケースで説明したように、外部キー フィールドを更新します。このフェーズの完了時に得られるのは、結合されたプロジェクト内で異なる記録です。

次に、それぞれのデータベース 3 およびデータベース 4 テーブルからの選択をデータベース 5 ターゲットに挿入します。これにより、テーブルがグローバルに異なる特異点に結合されます。

于 2013-06-13T06:08:22.687 に答える