3

私はこれが決して起こらないことを十分によく知っています。これまで。しかし、私は最近、データベースの設計や入力の検証があまり行われていない会社で働き始め、このような状況が発生しました。

'jobs'*と呼ぶテーブルがあります。Jobsには主キー「ID」があります。IDが1のジョブには、大量のデータが関連付けられています。ただし、愚かなことに、誰かがそのジョブをid 2として複製しました(これはこれまでに約500回発生しています)。両方の情報をすべてid1(または2、関係ありません)としてマージする必要があります。

列は、外部キーによってUPDATE:CASCADEおよびDELETE:RESTRICTでリンクされています。それらはすべてjobs_idと呼ばれるわけではありません。

ここでの私の唯一の(一見賢明な)オプションは次のとおりです。

  1. ID 1を使用されないことを保証できるものに変更します(2,147,483,647)
  2. 外部キーを一時的に削除しますDELETE:RESTRICT
  3. ID1のエントリを削除します
  4. ID 2を2,147,483,647に更新します(他のすべてのエントリとリンクするため)
  5. ID2,147,483,647をID2に変更します
  6. 削除を元に戻す:制限

どのコードも実際には削除を実行せず(制限はフェイルセーフ(DBで直接編集する人)と同じように存在します)、更新:カスケードが残っているため、データが同期しなくなることはありません。しかし、これは厄介に思えます。

これはトランザクションにラップされます。

各テーブル(〜180)と各列を反復処理して特定の名前/条件を見つけ、1から2に更新する何かを書くことができますが、新しいテーブル/列が登場したときにメンテナンスが必要になります。

これは頻繁に発生しており、すぐに発生しないように書き直すことはないため、「解決策」(絆創膏)は半自動である必要があります。

  • テーブルの本名ではありません。彼(または彼女)の身元は偽装されているため、彼(または彼女)はいじめられません。

入力に感謝します。

4

1 に答える 1

0

重複したレコードを特定する方法を知っていると仮定すると、同じ構造 (おそらく FK なし) で新しいテーブルを作成してから、値を新しいテーブルにコピーしながら元のテーブルをループします。重複にヒットした場合は、新しいテーブルに書き込むときに値を修正します。次に、オリジナルを削除し、temp の名前をオリジナルに変更します。

これによりテーブルがクリーンアップされますが、プロセスがまだ重複したエントリを作成している場合は、一意のキーを使用して今後の被害を制限できます。

于 2012-12-18T00:03:48.943 に答える