sql-server - SQLサーバーでユーザーフレンドリーなCheckConstraintエラーメッセージの戦略を探しています

Question

データベースをセットアップしていますが、行を作成/更新する前にチェックする必要がある行間の依存関係が多数あるテーブルがいくつかあります。多くのソースからの max/min/avg/stdev を持つ多くのフィールドがあります。

すべての関係に対して max>=min, avg>=min, avg<=max, stdev>=0 を確認する制約をいくつか作成することにしました。このようにDBに設定すると、データに誤って触れるとエラーがスローされます。このメカニズムは正常に機能します...エラー メッセージがユーザーの観点から見て恐ろしいという事実を除けば、基本的には制約が失敗したことを示し、20 の制約のうちどれが悪かったかを判断するのはユーザーに委ねられます。

制約の例外を確認し、データを実行して問題を見つけることで、クライアント コードでこれを修正できます。そのソリューションには、2 つの場所で検証が行われています...

エラーメッセージを各制約 (データベース内) に割り当て、例外メカニズムを介してそのメッセージを UI にフィルター処理することはできません。ビジネス ロジックでデータ検証を複製せずに、ユーザー フレンドリーなメッセージを UI まで浸透させるメカニズムはありますか? さらに重要なことは、この種の問題に対する基本的な戦略は何ですか?

Answer 1

サーバーから戻ってきて制御できる唯一のものは制約名です。そのため、これらができるだけわかりやすいものであることを確認するか、例外ハンドラーで制約名をユーザーフレンドリーなエラーメッセージにマップしてください。

このような状況では、各制約を可能な限り細分化して、各タイプの失敗が異なる制約の失敗になるようにします。もちろん、SQL Server が失敗した最初の制約のみを報告するという問題もあります。データは実際には複数の制約に失敗する可能性があります。

データを送信する前に、アプリケーションでチェックを複製する以外に、他にできることは考えられません。私はこの種の複製を Web ページのクライアント/サーバー検証に似ていると考える傾向があります。クライアント側で検証を実行して、ユーザー エクスペリエンスを向上させ、サーバーへの不要なラウンド トリップを回避します。ただし、クライアントの検証が何らかの理由で失敗した場合、サーバーはそれ自体を保護する必要があります。