4

データベースからレコードを削除するタイミングと、フィールド値を介して読み取り操作中に単純にレコードを非表示にするタイミングを知るためのさまざまな理論的根拠/解決策を誰かが提供できるかどうか疑問に思っていますis_hidden=1

私のアプリケーションは、ソーシャル ネットワーク/e コマース Web アプリケーションです。私はこの戦略を好む傾向がありますが、is_hiddenサイトが成長するにつれて、これがサイトのパフォーマンスの非常に悪いことにつながることがわかります.

これが私のリストです。リストのどのアイテムが不足していますか? リストの優先順位は適切ですか?

Delete:

  1. 理論的根拠: テーブルのサイズを減らす/データベースのパフォーマンスを向上させる
  2. 根拠: データを簡単に作成できる場合に便利
  3. ソリューション: SQLDELETE

is_hidden:

  1. 根拠: ユーザー/DBA がデータを復元できるようにする/機密性の高いデータや扱いにくいCREATEデータに役立つ
  2. 根拠:DELETE必要に応じて後で可能
  3. ソリューション: SQLSELECT ... WHERE is_hidden!=1

考え?

4

3 に答える 3

4

論理的な削除を実行する主な理由は、監査証跡がそれを必要とする場所です。たとえば、無効化された列と一緒に請求書テーブルがあり、通常は無効化された請求書を省略できます。これにより監査証跡が保持されるため、どの請求書が入力され、どの請求書が無効にされたかがわかります。

この理由から、論理的な削除が好まれる多くの分野 (特に金融) があります。通常、削除の数はデータ セットに比べて少なく、実際に削除することは望ましくありません。実際に削除すると、誰かがお金や実世界の商品の盗難をカバーできる可能性があるためです。「削除された」データは、それを必要とするクエリに対して表示できます。

db 以外の良い例は次のとおりです。まだ判読可能で、下に正しい値を書き込んでください。後でわかった場合は、調整エントリを書き込むか、反転と新しいものを書き込んでください。」その場合、主な理由は、いつ何が変更されたかを確認して、疑問が生じた場合にそれらの変更を監査できるようにすることです。

通常、そのような情報を確認する必要があるのは、財務またはその他の監査人である可能性があります。

于 2013-02-28T04:21:33.663 に答える
3

あなたはすでにあなたの質問ですべてを言っています:

DELETEはエントリを完全に削除し、

is_hidden=1で非表示になります。

したがって、将来データが必要になる可能性がある場合は、非表示メソッドを使用する必要があります。データが二度と使用されないことが確実な場合: delete を使用します。

性能について:

次の 2 つのテーブルを使用できます。

  • 目に見えるアイテムの場合は 1
  • 隠されたもののための1

または 3 つのテーブル:

  • 可視の場合は 1
  • 非表示の場合は 1
  • 1 をアーカイブとして、3 年以上前のすべての隠しデータを移動します。

または:

  • 表示および非表示の場合は 1 (is_hidden フラグを使用)
  • 1 古いエントリのアーカイブとして

それはすべてあなた次第です。しかし、Facebook や Google を見ると、何も削除されません。データ == お金 == 力 ;)

于 2013-02-27T15:55:14.383 に答える
1

パフォーマンスと開発の容易さに関する限り、プラットフォームでフィルター処理されたインデックス、インデックス付きビューなどを使用できる可能性があります。これは、論理的に削除されたデータを保持しても、システムにほとんど影響を与えないことを意味します。

于 2013-02-28T04:41:39.677 に答える