29

問題

製品と注文を扱う Web アプリケーションで、元従業員 (ユーザー) と彼らが処理した注文の間の情報と関係を維持したいと考えています。廃止された製品とこれらの製品を含む注文との間の情報と関係を維持したい。

ただし、元従業員、廃止された製品、廃止された製品グループなどを削除するなど、従業員が管理インターフェイスを整理できるようにしたいと考えています。

ソフト削除の実装を考えています。では、通常、これをどのように行うのでしょうか。

私の当面の考え

flag_softdeleted私の最初の考えは、ソフト削除可能にする必要があるオブジェクトのすべてのテーブルに「TINYINT NOT NULL DEFAULT 0」列を貼り付けることです。または、代わりにタイムスタンプを使用しますか?

次に、関連する各 GUI に「削除済みを表示」または「削除を取り消す」ボタンを用意します。このボタンをクリックすると、ソフト削除されたレコードが結果に含まれます。削除された各レコードには「復元」ボタンがあります。これは理にかなっていますか？

あなたの考え？

また、関連するリソースへのリンクをいただければ幸いです。

4

6 に答える 6

38

それが私のやり方です。デフォルトで 0 に設定されているis_deletedフィールドがありWHERE is_deleted = 0ます。

私は可能な限りハード削除を避けるようにしています。それらは時々必要ですが、私はそれを管理者専用の機能にしています。そうすれば、ハード削除できますが、ユーザーはできません...

編集：実際、これを使用して、アプリにソフト削除の複数の「レイヤー」を含めることができます。したがって、それぞれがコードになる可能性があります。

  • 0-> 削除されていません
  • 1-> 論理的に削除され、管理ユーザーの削除済みアイテムのリストに表示されます
  • 2-> 論理的に削除され、管理者ユーザー以外のユーザーには表示されません
  • 3-> 開発者のみに表示されます。

他の 2 つのレベルがあると、管理者と管理者は削除されたリストが長くなりすぎた場合にクリーンアップできます。また、フロントエンド コードは をチェックするだけis_deleted = 0なので、フロントエンドに対して透過的です...

于 2011-02-16T18:33:07.377 に答える
11

論理的な削除の使用は実装するのが一般的であり、次のような多くのことに役立ちます。

  • ユーザーが何かを削除したときにユーザーのデータを保存する
  • 何かを削除するときに自分のデータを保存する
  • 実際に起こったことの記録を残す (一種の監査)
  • など

私が指摘したいことが 1 つあります。それは、ほとんどの人が見逃していることです。アプリケーションのユーザーは、あなたと同じように削除について理解していません。

さまざまな程度の削除があります。典型的なユーザーは、次の場合に物を削除します

  • 間違いを犯し、悪いデータを削除したい
  • もう画面に何かを見たくない

問題は、削除の意図を記録しないと、アプリケーションが誤ったデータ (作成されてはならないデータ) と歴史的に正しいデータとを区別できないことです。

次のデータを見てください。

PRICES | item | price | deleted |
       +------+-------+---------+
       |   A  |  101  |    1    |
       |   B  |  110  |    1    |
       |   C  |  120  |    0    |
       +------+-------+---------+

一部のユーザーは、アイテム B をもう販売していないため、アイテム B の価格を表示したくないと考えています。それで彼はそれを削除します。別のユーザーが誤って商品 A の価格を作成したため、それを削除し、意図したとおりに商品 C の価格を作成しました。では、全商品の価格表を見せていただけますか？いいえ、エラーの可能性があるデータを表示する必要がある (A) か、現在の価格以外をすべて除外する必要がある (C) ためです。

もちろん、上記のことはさまざまな方法で対処できます。私が言いたいのは、削除の意味を明確にし、ユーザーがそれを誤解しないようにする必要があるということです。1 つの方法は、ユーザーに選択 (非表示/削除) を強制することです。

于 2011-02-16T20:00:06.260 に答える
6

そのテーブルにヒットする既存のコードがある場合は、列を追加してテーブルの名前を変更します。次に、アクティブなレコードのみを選択する現在のテーブルと同じ名前のビューを作成します。そうすれば、既存のコードが壊れることはなく、論理的な削除列を持つことができます。削除されたレコードを表示する場合は、ベース テーブルから選択します。それ以外の場合は、ビューを使用します。

于 2011-02-16T18:37:12.977 に答える
1

あなたが言及したように、私はいつも削除された列を使用してきました。それ以上のものはありません。レコードを削除する代わりに、削除済みフィールドを true に設定するだけです。

私が作成したコンポーネントの中には、ユーザーが削除されたすべてのレコードを表示して復元できるようにするものもあれば、削除済み= 0のすべてのレコードを表示するだけのものもあります。

于 2011-02-16T18:33:58.433 に答える
1

あなたのアイデアは理にかなっており、本番環境で頻繁に使用されていますが、それを実装するには、新しいフィールドを考慮してかなりの量のコードを更新する必要があります。もう 1 つのオプションは、「論理的に削除された」レコードを別のテーブルまたはデータベースにアーカイブ (移動) することです。これも頻繁に行われ、問題は (再) プログラミングではなくメンテナンスの問題になります。(テーブル トリガーが削除に反応して、削除されたレコードをアーカイブすることができます。)

本番コードの大幅な更新を避けるためにアーカイブを行います。ただし、deleted-flag フィールドを使用する場合は、それをタイムスタンプとして使用して、ブール値を超える追加の有用な情報を提供してください。(Null = 削除されていません。) レコードの削除を担当するユーザーを追跡するために、DeletedBy フィールドを追加することもできます。2 つのフィールドを使用すると、誰がいつ何を削除したかを示す多くの情報が得られます。(2 つの余分なフィールド ソリューションは、アーカイブ テーブル/データベースでも実行できるものです。)

于 2011-02-16T18:36:45.713 に答える
0

私が遭遇した最も一般的なシナリオは、あなたが説明したものであり、またはまたはのステータスを表すことtinyintさえあります。これが「ビジネス」データと見なされるか「永続」データと見なされるかに応じて、ストアド プロシージャ内に直接格納され、アプリケーション コードには認識されないなど、可能な限り透過的にアプリケーション/ドメイン ロジックに組み込むことができます。しかし、これはニーズに合った正当なビジネス情報であるように思われるため、コード全体で知る必要があります。（そのため、ユーザーは削除されたレコードを表示できます。）bitIsActiveIsDeleted

私が見た別のアプローチは、2 つのタイムスタンプの組み合わせを使用して、特定のレコードのアクティビティの「ウィンドウ」を表示することです。それを維持するにはもう少しコードが必要ですが、利点は、事前に決められた時間にそれ自体を論理的に削除するようにスケジュールできることです。期間限定商品は、たとえば作成時にそのように設定できます。(レコードを無期限にアクティブにするには、最大値 (または、途方もなく遠い将来の日付) を使用するか、それでnullよければ終了日を設定することができます。)

それからもちろん、時々削除されたり削除されていないものについてさらに検討し、そのための何らかの監査を追跡します。フラグ アプローチは現在のステータスのみを認識し、タイムスタンプ アプローチは最新のウィンドウのみを認識します。しかし、監査証跡のような複雑なものは、問題の記録とは別に保存する必要があります。

于 2011-02-16T18:38:01.680 に答える