本社と支店を持つ企業でアプリケーションを実行しています。各ブランチには、個別のローカルサーバーとDBがあります。マスターサーバーとDBは、バッチ更新によって毎日更新されます。このような状況でIDの競合を克服するにはどうすればよいですか。
例：ブランチAにID10のレコードがあります。参照ID10（外部キー）のトランザクションもありますが、これをマスターデータベースに保存しているときに、一意のIDが変更される可能性があるため、トランザクションが一致しません。
plsはこれを解決するために私を助けます...
みんなに感謝します。
今のところ技術的な側面を忘れて、ビジネス/アプリケーションのロジックを明確にします。競合が発生する可能性のある場所（顧客レコード、トランザクション、すべてのデータ）は、あなたの投稿からはまったくわかりません。なぜ競合が発生するのですか？競合はどのように解決されますか？データで何が起こっているのか、そしてビジネスが何を期待しているのかを正確に理解したら、技術的なソリューションを調べることができます。
GUID、数値範囲、マッピングテーブルなどの提案は非常に役立ちますが、解決しようとしている問題とビジネスソリューションが何であるかはまったくわかりません。すべてのデータを物理的に1か所にまとめるのは簡単です（SSISから始めるのが良いでしょう）。本当の問題は、データをマージするためにどのようなルールに従うかということです。
uniqueidentifierこれを克服するには、ブランチのデータ型として使用できますID。
したがって、各データベースはNEWID()、マスターデータベースがキーを変更することを心配することなくIDを作成できます。これは、それが普遍的に一意であるためです。
データ型を変更したくない場合は、各ブランチに番号範囲がある可能性があります。各ブランチで作成されるレコードの数によって異なります。
The master server and DB is updated daily by batch updation
バッチ更新の正確な実行方法やデータベースの大きさ、およびこの種の問題に直面しているテーブルの数の詳細がわからない場合、可能な方法の1つは、マッピングテーブルを維持することです。
バッチ更新ロジックでは、
新しいレコードの場合、最初にレコードをマスターテーブルに挿入し、次にマスターから生成された新しいIDを使用して、2つのID間の関係を格納するbranch、branchID、MasterIDなどの詳細を含むレコードをマッピングテーブルに挿入します。
既存のレコードの場合、マッピングテーブルと結合し、マッピングテーブルのmasterIDを使用してレコードを更新します
通常、SQL Serverでは、バッチ更新がジョブである場合、SSISを使用して、SSISパッケージ内にこの種のロジックを含めることができます。
さらに、それはあなたのデザインに依存しますが、通常は
ソースDB->ステージングDB->宛先DB
あなたの場合、
ブランチDB->ステージングDB->マスターDB
そのようなETLの種類のタスクのために。このような場合、マッピングテーブルはおそらくステージングデータベースに存在する必要がありますが、そのような設計がない場合（実際にそうする必要があります）、これらのマッピングテーブルは宛先、つまりマスターデータベースにも存在できます。