ストアド プロシージャで RAISERROR を使用してユーザー メッセージ (つまり、エラー メッセージではなくビジネス関連のメッセージ) をアプリケーションに返すことについて、人々がどう考えているか知りたいです。
私の会社の上級開発者の何人かは、このメソッドを使用して、C# コードで SqlException をキャッチし、メッセージを取得してユーザーに表示しています。私はこの方法に満足しておらず、ストアド プロシージャからのこれらのタイプのユーザー メッセージを他の人がどのように処理しているかを知りたいと思っています。
私はこれを行いましたが、通常はビジネスの「エラー」メッセージを渡すためでした。基本的に、何らかの理由で標準の FK 制約を適用できないデータ構成を配置する必要がありました。
それらが実際に「エラー」である場合、あまり問題はありません。レコードを挿入し、RAISERROR を使用してスローする場合 ("You have successfully registered for XYZ!")、問題があります。もしそうなら、out パラメータを使用するためのチーム/部門/会社の開発標準を考え出すでしょう。
このようにRAISERRORを使用することは、実際には良い考えではありません。これは、一般的に眉をひそめているフロー制御ロジックとして例外を使用するのと同じです。
代わりにOUTパラメータを使用してみませんか？それがまさに彼らの目的です。OUTパラメータをサポートしていないデータベースやクライアントAPIは考えられません。
ストアド プロシージャが 2 セットのデータを返すようにします。1 つ目は実際に返されたデータを含むことができ、2 つ目はテキスト メッセージを返すことができます。その後、アプリ コードは必要な場所でデータを使用し、返されたメッセージを表示できます。
これほど古い質問に答えるのは悪い形ですか？誰でも...
あなたの毎日のステータスメッセージにとって、これは悪いことであり、私は上記のほとんどすべての答えに同意します。しかし、私はこれが長いバッチの間に進行状況を示すために非常に効果的に使用されるのを見てきました。例については、JensKによるバッチおよびストアドプロシージャからのフィードバック/進行状況の取得を参照してください。あなたはそれをするためのかなりハードコアな理由を持っている必要があります、しかしあなたがそれを必要とするとき、あなたはそれを必要とします、そしてそれは素晴らしいです。
例外は、状況が例外的であり、処理ロジックがない場合にのみスローする必要があります。また、例外の発生とキャッチにはコストがかかります。
例外を使用しないでください
出力パラメーターを使用するか、複数の結果セットを返して、ストアード・プロシージャーから情報を渡します。
次のように、ストアド プロシージャの RETURN 値を使用します。
CREATE PROCEDURE checkReturnValue
AS
BEGIN
DECLARE @err AS INT
SET @err = 0
IF (rand() < 0.5)
BEGIN
SET @err = 1
END
SELECT * FROM table
PRINT @err
RETURN @err
END
ストアド プロシージャを呼び出すアプリケーションの RETURN 値を確認します。
エラーが発生した場合はエラーを発生させ、出力変数または戻り値でステータス情報を返します。
SQL ストアド プロシージャの出力パラメーターを使用する必要があります。
http://msdn.microsoft.com/en-us/library/ms378108.aspxから:
CREATE PROCEDURE GetImmediateManager
@employeeID INT,
@msg varchar(50) OUTPUT
AS
BEGIN
SELECT ManagerID
FROM HumanResources.Employee
WHERE EmployeeID = @employeeID
SELECT @msg = 'here is my message'
END
定義上、これらの種類のメッセージはおそらくビジネス ロジック層で処理/生成する必要があるため、ストアド プロシージャがビジネス関連メッセージを返さないようにします。
例外は例外的 (まれ) であるべきです。エラーに対してのみ RAISEERROR を使用します (たとえば、このデータをすべてインポートしようとしたときに、行の 1 つに間抜けなデータがあったため、トランザクションをロールバックしました)。また、発生したエラーの重大度にも細心の注意を払う必要があります。これは、エラーがどのように伝播し、接続に何が起こるかに大きな影響を与える可能性があります。
これで十分でない場合は、戻り値または出力変数を使用してみてください。
列のチェックなどをいじっても構わないのであれば、何が起こったかに基づいて別のものを返すことができると思います。
すべて問題なければ、通常どおりデータを返します。何かがうまくいかない場合は、何が悪いのかを説明する Error という名前の列を含む結果を返します。データを処理してそれに応じて行動する前に、この列の列名を確認してください。
あなたが本当にRAISERRORに反対するなら、私の頭の上から離れてください。
「ビジネス」エラー メッセージが、データベース レベルで基本的な低レベルのビジネス要件を満たすために設定されたデータベース制約に違反しているという意味でのデータベース エラー メッセージである場合のみ。
データベース層では避けるべき高レベルのビジネス ロジックには使用しないでください。データベース層は常に変化が最も遅いため、非常にゆっくりと変化し、変化しないビジネス ロジックのみが存在する必要があります。
そのため、非アクティブ/無効な顧客の注文に関するメッセージには「はい」かもしれませんが、90 日以内に残高がある顧客の注文には「はい」とは言えません。最初のルールは恒久的で、2 番目のルールは設定可能で、月単位でビジネスの気まぐれに左右される可能性があります。
複数のネストされたストアド プロシージャの深さから戻るために raiseerror を使用しましたが、ストアド プロシージャの最終層は、呼び出し元の言語 (この場合は JDBC 経由の Java) に発生する前に常に例外をキャッチします。最も外側の層にあるストアド プロシージャ キャッチは、XML メッセージに変換されて JDBC 呼び出しに転送されます。ルート要素には、慣例により、feedback 属性が含まれている必要があります。feedback 属性の値には、常に ok、alert、または error のいずれかのデコレーターがあります。OK は続行を意味し、ここには何も表示されません。Alert は継続することを意味しますが、残りのフィードバックをユーザーに表示します。エラーはパントを意味します。ヘルプ デスクに連絡してください。
早期にチェック/キャッチできない場合は、他のことを行うのが難しい場合があります。
データの「最後の停止」であり、そこでチェックする必要があったため、テーブルの挿入/更新の制約として作成および使用したプロシージャに raiseerror を記述する必要がありました。
一般的に、DB からエラーが返される場合は..お尻の痛みであり、多くの努力なしにユーザーに「良い」フィードバックを提供するのは難しいですが、挿入するまでわからない場合があります/更新：P
私の冒涜的な2セント：
テキストベースのメッセージは、HTTP などの Web 上で非常にうまく機能します。メッセージングが人間が読めるテキストで行われるシステムを作成、送信、デバッグするのは簡単です。
そのため、SQL Server レイヤーとその上のレイヤーとの間のメッセージングについても同じことが言えます。メッセージングの一部としてテキストを使用すると、開発がより機敏になり、デバッグが容易になる可能性があります。おそらく、上級開発者は実用的であり、正しいという先入観を脇に置いてもよいでしょう。
正しいという概念に基づくのではなく、それ自体のメリットに基づいて設計の選択について議論してください。（ソフトウェア開発にも流行があります）