単純なアプリを作成しているとします。モデルは、「プロジェクト」には「カテゴリ」があるということです。プロジェクトのカテゴリは、可能なすべてのカテゴリを含むドロップダウン リストから選択して編集できます。
ユーザーは次のカテゴリを作成します: C1、C2、C3。
ユーザーは、次のプロジェクト、カテゴリの関連付けを作成します: [P1, C1]、[P2, C2]、[P3, C3]
その後、カテゴリ C2 は削除されました。ここで、ユーザーがプロジェクト P2 のカテゴリを編集しようとすると、いくつかの問題が発生します。ドロップダウン リストに入力するには、カテゴリを取得する必要があります。ただし、削除されたカテゴリは取得されません。したがって、C2 は取得されません。(削除されたカテゴリが取得された場合、ドロップダウン リストは削除された使用できないフィールドでいっぱいになります)
b. C2 も取得すると、ユーザーが削除されたカテゴリ C2 を P2 に再度割り当てることができるリスクがあります。
これを処理するための最良の設計アプローチは何ですか?
彼らに C2 の削除を許可しないでください。または、代わりに、必要に応じて C2 を削除できるようにしますが、システム内のすべての C2 カテゴリを未定義のカテゴリに変更します。そうすれば、次にプロジェクトを編集するときにカテゴリを選択する必要があります (以前に作成された「未定義」のカテゴリを指しているため、カテゴリは引き続き有効です)。
参照整合性の問題が発生しています。
既存のプロジェクトによってまだ参照されている限り、カテゴリを削除することはできません。ただし、フラグ IsDeleted を追加することを検討して、新しいプロジェクトをそのカテゴリに割り当てることを許可することができます。
カテゴリを存在から削除せず、適切な画面/ドロップダウン メニューから非表示にするだけで、歴史的な理由からレポートでデータを使用できるようにする「廃止」フィールドを使用しました。
一般に、このような構造要素の場合、データ ストレージが深刻に不足している場合を除き、要素を削除済みフラグを付けてそのままにしておくと、削除される前から要素を参照しているものが破損することはありません。または、それを参照するものもすべて削除するリップル削除を実装します。
一貫性を維持するために、削除することはできませんC2が、実際に削除する代わりに無効にするオプションを追加できます。そうすれば、新しいプロジェクトは に割り当てられませんC2。
他の人が言及したソフト削除でこれを処理しました。次に、ドロップダウン リストに入力するときに、C2 に割り当てられているプロジェクトを変更するときに、C2 をドロップダウン リストの一番上に追加します (削除されたカテゴリのみ)。そうすれば、C2 にあるものを C2 の外に移動できますが、C2 に新しいものを配置することはできません (C2 にまだない場合は、ドロップダウン リストにないため)。
これを行うコードは特にきれいではありませんでしたが、それほど難しくもありませんでした。現在、プロジェクトは開いていませんが、興味があれば後で詳細を追加できます。
参照テーブルの場合、すべての古いデータを新しい有効なカテゴリに再割り当てするか、有効な日付や日付範囲など、有効な時期を表すいくつかの追加フィールドをカテゴリに残す必要があります。
ブール値の「削除済み」フラグは、カテゴリを更新せずに古いデータを編集できない (できない可能性がある) ことを意味しますが、古いデータが編集されるまで保留することができます。