モデルを時々削除するだけでいいですか？
一種のCMSを開発しています。その中で、ユーザーは「顧客」を作成できます。なんらかの理由で、ユーザーはその顧客を削除したい場合があります。顧客が誤って作成されたためか、顧客が二度と戻らないと考えているか、単にOCDであり、すてきなクリーンなシステムが必要な場合があります。
ただし、顧客はシステム全体のさまざまな場所で参照されます。たとえば、予約は顧客にリンクします。顧客が予約にリンクされ、後で削除された場合、予約は本質的に破損します。現在では、重要な履歴情報が欠落しています。これを防ぐために、データベースレベルで外部キー制約を作成しました。
これが私が考えていることです：要求されたときに顧客を削除しようとすることでこれらの制約を活用できますが、失敗すると代わりにソフト削除を実行します。このようにして、参照整合性を維持しながら、実際にはどこでも使用されていないソフト削除された顧客からの残骸の蓄積を防ぐことができます。
要点をまとめると：
- お客様がnotがシステムのどこかで参照されている場合、実際の完全削除を実行します
- 顧客isがどこかで参照されている場合、一時的な削除を実行します（つまり、レコードに削除済みのフラグを付けますが、保持します）
よろしいですか？私が懸念しているのは、「削除」ボタンを押すまでは何をするか本当にわからないということですが、ユーザーの観点からは、あまり重要ではありません。他に問題はありますか？
使いやすさの観点からは、ユーザーがソフト削除とハード削除のどちらを使用しても、レコードは削除されます。
これは絶対的な真実ではありませんが、削除された顧客がリンクされた予約を通じてアクセスできる場合。これは、たとえば、計画する必要があるものです。それと対話するための完全な機能を持たない顧客を示すだけでいいですか？.
ほとんどのシステムでは、実際にレコードを削除することは決してなく、アイデアのようにフラグでそれらを非表示にするだけであるのが普通だと思います。 GoogleやFacebookのような大企業でも、実際には何も削除しません 。
これはUXの質問のようには見えません。UXの観点からは、顧客は違いを理解できないからです。
しかし、それが役立つ場合は、システム設計の観点から、関係の依存関係がデータの保持/削除ポリシーを指示することを許可することは、良い設計慣行ではありません（「尻尾を振る」ことを許可します）。削除の伝播を今すぐ書く時間がない場合は、便宜のためにそれを実行しますが、長期的には、ビジネスに適切なポリシーを理解し、削除（またはソフト削除）ロジックを記述する方が良いと思いますそれに応じて。部分的な削除は便利かもしれませんが、独自のコストが伴います（例：不規則な/一貫性のないデータスコープの管理）。
ビジネス上の決定は、とりわけ、ストレージのコスト、顧客のプライバシー、および内部分析のニーズに依存する場合があります（たとえば、データを削除すると、時系列分析や行動分析を行うことが困難になります）。記録を残したい場合はプライバシーを管理できることに注意してください...たとえば、ソフト削除で顧客データを匿名化できます。