データベース テーブルの大部分が他の 1 つのテーブルと強い関係を持つアプリケーションがあります。現在、外部キーを使用して参照整合性を強制していますが、これが本当に最善のアプローチであるかどうか疑問に思っています。プライマリ テーブルのデータは、ビジネス ユーザーが管理インターフェイスから削除できます。つまり、カスケード削除を実行する (または複数の削除ステートメントを記述する) 必要がありますが、他のすべてのデータを本当に削除する必要があるかどうかはわかりません。同時に。それは、後日役に立つ*かもしれない*多くのデータである可能性があります (おそらく報告しますか?)。ただし、二次テーブルのデータは、基本的に、一次テーブルとの関係が存在しない限り、アプリケーション自体には役に立ちません。
6 に答える
8
オプションがあれば、私は常にデータを保持しています。また、外部キーが既に配置されているため、整合性違反に対する保護が組み込まれています。
ユーザーがレコードを「削除」してアプリケーションから隠したい場合は、データベースから物理的に削除するのではなく、レコードを非アクティブとしてマークする「仮想削除」戦略を検討してください。
実装に関しては、データベースに応じて、テーブルのブール/ビットロジックに相当するものを追加します。デフォルトでは、すべての行に true/1 が割り当てられます。「削除」は false/0 としてマークされます。
于 2009-02-24T13:22:25.883 に答える
2
カスケード削除を使用しなくても、外部キーと関係を使用して参照整合性を適用できます。データを削除するよりも、データを保持して適切に管理/アーカイブする方が良いことが多いことがわかっているため、カスケード削除を使用することはめったにありません。
独自の削除ロジックを記述して、独自のビジネス ルールをサポートするだけです。
論理的な削除も同様にうまく機能し、私はそれらを広範囲に使用しています。
于 2009-02-24T13:21:40.660 に答える
1
一部のデータは削除したくありません。そもそもデータがどこに属していたのかわからない不正なデータになってしまう可能性があります。それはすべてかゼロかのどちらかです。
ソフト削除、つまり、レコードが「削除」されているかどうかを決定するビットフィールドをすべての行に持つことが、進むべき道です。そうすれば、API でレコードが削除されているかどうかを確認するだけで == true になり、アプリケーションから非表示になります。
あなたはデータを保持しますが、誰もアプリケーションからデータを取得することはできません.
于 2009-02-24T13:27:34.513 に答える
0
原則として外部キー制約を使用すると思います。これにより、DB設計が長期的に「保護」され、データの整合性自体も保護されます。制約は、設計者の決定を明示的に述べるためにも存在します。
非常に大規模なデータベースでは制約が取り除かれているのを見てきました。これは、パフォーマンスを比較し、外部キーのオーバーヘッドが大きい場合、それらを使用しない理由の 1 つです。
于 2009-02-24T13:24:06.613 に答える
0
logical/soft deleteを使用します。これは基本的に、問題のテーブルにもう 1 つの列 (おそらく bit column Deleted) を追加することを意味します。これにより、特定の行が削除済みとしてマークされます。
とはいえ、「削除された」データはまさにそれです: 削除されました。したがって、レポートや同様のもので論理的に使用することはできません。これを克服するために、Hidden列を導入して、論理的な意味を保持したまま特定の行を非表示にします。
于 2009-02-24T13:24:14.850 に答える
0
物理的な削除は絶対にしないでください。BOOL フラグ IsDeleted を追加して、レコードが削除されたことを示すことができます。レコードを「削除」したい場合は、フラグを True に設定するだけです。
于 2009-02-24T13:39:11.787 に答える