誰もがたまにこの問題に遭遇すると思います。マージする必要のある自動番号付けの主キーを持つ2つのテーブルがあります。自動番号付けの主キーがアプリケーションで生成されたキーを優先して使用される理由はたくさんありますが、他のテーブルとのマージは最大の欠点の1つである必要があります。
発生するいくつかの問題は、IDの重複と外部キーの同期のずれです。これに取り組むためのあなたのアプローチを聞きたいです。私はいつも問題にぶつかるので、誰かが何らかの一般的な解決策を持っているかどうか非常に興味があります。
- 編集 -
GUIDまたはその他の非数値キーの使用を提案する回答に応じて、事前に自動番号キーを使用する方がよいと思われる場合（および後で後悔する場合）、または他の誰かのプロジェクトを引き継ぐ場合があります。または、使用する必要のあるレガシーデータベースを取得します。ですから、データベース設計を制御できなくなったソリューションを本当に探しています。
ソリューションは次のとおりです。
単純なIDフィールドではなく、主キーとしてGUIDを使用します。重複を回避する可能性は非常に高いですが、GUIDは使いにくく、クラスター化インデックスとうまく連携しません。
主キーを複数列のキーにし、2番目の列は、マージされたデータのソースを特定することにより、重複する値を解決します。移植性があり、クラスター化インデックスでより適切に機能しますが、開発者は複数列のキーを嫌います。
疑似キーの代わりに自然キーを使用します。
マージされたテーブルの1つに新しい主キー値を割り当て、これらの変更を依存する行にカスケードします。これにより、マージ操作がETL操作に変更されます。これは、データベースの設計を変更できない場合にレガシーデータに使用できる唯一のソリューションです。
万能の解決策があるかどうかはわかりません。状況に応じて、これらのいずれかを選択してください。
うーん、AlexKuznetsovの答えにコメントを入れただけなのに、ちょっと熱心なので、全体的に答えます。
id1とid2を自動番号付けの主キーとして、table1とtable2という名前のテーブルを考えてみます。これらは、id3（自動番号以外の主キー）を使用してtable3にマージされます。
なぜだめですか：
UPDATE table SET id1 = id1 * 2、table2を参照するFKフィールドに対して、を実行します。UPDATE table SET id2 = (id2) * 2 + 1INSERT INTO table3 SELECT id1 * 2 AS id3, ... FROM table1 UNION ALL SELECT id2 * 2 + 1 AS id3 FROM table2より高い乗数を使用するだけで、3つ以上のテーブルでも機能します。
このような不測の事態に備えて設計している標準的なアプローチの1つ（標準的なアプローチではない場合）は、整数ではなく主キーにGUIDを使用することです。オーバーラップが発生しないことが保証されるため、マージは比較的簡単です。
再設計を除けば、テーブルに挿入し、新しい主キーを取得することを受け入れ、古いIDから新しいIDへのマッピングを維持していることを確認してから参照データを挿入する必要があると思います。 FKの再マップなどを使用します。データに「ビジネスキー」があり、挿入後も一意のままである場合、これにより、マッピングを追跡する必要がなくなります。
そのようなテーブルは2つしかないので、1つのテーブルに偶数のID（0,2,4,6、...）を、別のテーブルに奇数のID（1,3,5,7、..。）を含めることができます。 ）。
マージするテーブルにも自然キーがあると仮定すると、プロセスは難しくありません。自然キーは、重複排除と参照の正しい再割り当てに使用されます。サロゲートキーの値はいつでも再番号付けできます。これは、そもそもサロゲートを使用する主な利点の1つです。
したがって、これを代理キーの問題とは見なしません。ただし、常に自然キーを適用する必要があります（実際、私は「ビジネスキー」という用語を非常に好みます）。これらのテーブルのビジネスキーがない場合は、必要なすべてのキーが適切に実装されるように再設計するのがよいでしょう。