ビジネスアプリケーションで外部キー制約を伝える方法は？
ユーザーがデータを編集するさまざまなビジネスフォームを備えたビジネスアプリを持っています。ユーザーがレコードを削除すると、「FK_ABC_AA ..制約違反など」と表示されます
それ以上のことをして、ユーザーに何か有益な情報を伝えたいです。
一部のアプリケーションで「他のデータが参照しているため、このレコードを削除することはできません。」と表示されるだけです。またはそれらの線に沿って何か。情報が足りないので気に入らない。
データベースからのエラーメッセージを解析して、人間が読める特定のメッセージを表示できますが、これを行う前に「におい」がします。そのような情報を表示する好ましい方法はありますか？
編集：
私はそれを言及する必要があります：
私の場合、アプリケーションはクラッシュしていません。レコードは削除されません-トランザクションはロールバックされます。表示されるのは単なるメッセージです。
この状況では、関連するレコードを削除することは実際的ではありません。これは大きなERPのようなデータベースです。それで、顧客を作成してすぐに削除したいとしましょう-それは大丈夫です。ただし、関連付けられた注文を持つ顧客を削除したくない場合は、.
ボタンを無効にすることも現実的ではありません。関係を追加するときに同じ場所を継続的に変更する必要があるためです。また、削除できるかどうかを確認するためだけに、レコードを取得するたびに追加のクエリを実行する必要があります。
ほとんどのユーザーは削除を実行する権限さえ持っていないので、誰にとってもいいことではありません。
これは、ユーザーが操作をいつ実行するかを真剣に知る必要があるアプリケーションのようです。この場合、not関数を非表示にしたり、他の人が示唆したようにエラーメッセージを非表示にしたりできます。
あなたの説明から、これらは管理者または信頼されているユーザーであり、彼らが何をしているか（顧客の削除など）に精通していると推測しています。これらの制約に違反することはできず、ユーザーに制約の意図と必要なアクションのコースを示すを指定する必要があります。
顧客からのすべての注文を削除する前に顧客から削除する必要がある場合は、そのことをユーザーに伝えます（可能な場合はどこででも可能です）。すぐにこれを行うオプションを提供することを検討してください。
[キャンセル]オプション（強調表示）と[親レコードと子レコードの削除]オプションを提供します。この場合、「顧客と関連するすべての注文を削除する」になります。ユーザーが理解できる言葉で説明してください。このルートに進んだ場合、削除ボタンを押すとどうなるかを明確に示してください。
関連付けられたレコードを一度に削除できない場合は（削除できないことを示唆しています）、親レコードを削除できるようにするために何を実行する必要があるかを伝えます。その顧客からのすべての注文を削除または閉じる必要がある場合は、その旨を伝えます。 完全に不可能な状況の場合は、削除ボタンを無効にし、このレコードを削除できない理由を説明するツールチップに理由を示します。これは頻繁に起こるべきではないようです。
ボタンを無効にすることはできないとおっしゃっていますが、実際に行う必要があるのは、ボタンをクリックする前とを確認することだけです。顧客を開いたときにあなたが知っているどうしても削除できない場合は、ボタンを無効にしてください。削除できるように見える場合は、ボタンをクリックした後、チェックをオフにして、レコードを削除できるかどうかを確認します。できない場合は、エラーメッセージを表示してください。両方を行うことができない実用的またはUXの理由はないと思います。
ユーザーはアプリケーションが期待どおりに動作しない理由をユーザーが気にしないであるため、これらのメッセージをユーザーに最初に表示することはありません。これらのエラーは、QA部門がソフトウェアをリリースする前に処理するか、または不可能であれば、さらなるバグレポートのためにログファイルに保存する必要があります。
削除するレコードに他のテーブルの関連レコードが含まれている場合、それは次のことを意味します。
- 関連するレコードを削除する必要があります。その場合は削除してください。
- または、最初のレコード自体を削除してはなりません。この場合、UIの削除ボタンを無効にする必要があります。これが無効になっている理由を説明するツールチップが表示される場合があります。それが不可能な場合（たとえば、外部レコードが他のユーザーによって追加されている間）、レコードを削除できないことをユーザーに通知します。
私はsvickを使用していますが、エンティティのアクティブ/非アクティブステータスフラグを優先します。ボタンを有効/無効にするだけでなく、レコード自体（つまり、UIテーブル内）にカラーリングを使用して、アクティブステータスであることを示し、参照整合性を保持し、1つの単純なクエリですべてを取得し、非アクティブと実際の混乱を防ぐ削除されました。監査テーブルは通常、action = deleted、user = some_user、date = some_long、status = Active ...、またはstatus = Inactive ...のようなデータを保持するため、削除（アクション）は非アクティブ化（ステータス）とは異なります。
別のオプションは、削除されたかどうかを示すフラグを各行に設定することです。
この方法では、行を削除しても外部キーに違反しません。また、行の「削除を取り消す」場合、または削除された行に関する情報を表示する場合は、これが可能です。
私が最近のアプリで行ったことは、レコードが削除できるかどうかを確認することであり、レコードが削除可能でない限り、ユーザーに削除させないようにしています。注意深く行うと、これを行うのが合理的に効率的である可能性があります。つまり、ユーザーには関係ない理由ですが、ユーザーはこのレコードを削除できないことを知っているだけです。うまくいけば、彼らはなぜ彼らがさらに探求するように導くべきであるかについての理由を知るでしょう。
もちろん、これは常に関連しているわけではありませんが、彼らが意味のあることだけをすることを許可されるべきであるという原則は固守されるべきです。問題が何であるかを示すために、情報またはクリックスルーも提供する必要がある場合があります。子レコードがある場合は、レコード数を示し、クリックスルーでこれらを表示することができます。
ただし、詳細なソリューションは、アプリケーションとユーザーにより固有のものになります。アプリケーションで機能する方法は、仕様によって異なります。
さて、あなたはあなたのアプリケーションをより有益なものにしたいと思います。データがわかっていて、スキーマがわかっていれば、アプリケーションのビジネスルールを通じてユーザーに適切に通知できます。
- ユーザーが削除ボタンを押す
- スキーマを照会して、FK関係とFKレコードがあるかどうかを確認します
- FKレコードとおそらくは概要があることをユーザーに通知します
- 続行するかキャンセルするかを選択する
- ユーザーが続行することを選択した場合は、最初にFKレコードを削除するように指示します。
- ユーザーが[キャンセル]を選択した場合、[削除]ボタンのアクションをキャンセルします
データが関連付けられているレコードの削除ボタンを無効にすることをお勧めします。
ユーザーが削除できない理由をユーザーが気にしていると思われる場合は、削除ボタンの代わりに、ユーザーに注文が関連付けられていること（または特定の理由が何であれ）を知らせる情報ボタンを配置します。