3

これは、SPが良いか悪いかについての質問ではありません。または、C＃でSQLステートメントを書くのが良いか悪いか。

間もなく、典型的な在庫/請求管理システムである新しいプロジェクトの作業を開始します。これは、言語として.NetとC＃を使用して開発されます。データベースはまだ完成していません。

このアプリケーションではストアドプロシージャの使用は許可されておらず、中程度から複雑なデータベース操作が行われます。つまり、SPを使用して簡単に記述できたロジックは、C＃とADO.Netを使用して記述しなければならないものになります。

ここで、顧客が5つのアイテムを選択し、カウンターで請求書を生成する準備ができている、非常に仮想的なユースケースを取り上げます。これには通常、次のデータベース操作があります。

  • INVENTORYテーブルをチェックして、5つのラインアイテムすべてが使用可能かどうか（十分な数量）を確認します。
  • いずれかのアイテムが利用できない場合–請求書からアイテムを削除し、BILLテーブルを更新します
  • INVENTORYテーブルの数量フィールドが更新され、販売されたアイテムから数量フィールドが差し引かれます。
  • 他のテーブルのアラート/更新は、アイテムのしきい値数量が特定のポイントを下回ったことです。

このシナリオを見ると、これはすべてSPで簡単に実行できたはずです。これには多くのクエリ、IF条件、可能なループなどが含まれており、SPの優れた候補のように見えます。私が専門家に求めていたのは：

  1. C＃およびADO.Netでそのようなコードを作成するためのベストプラクティスはありますか。C＃では、通常、ADO.Netを使用して同じコードを再作成できます…。しかし、これが唯一の方法ですか、それとも正しい方法ですか？
  2. ストアドプロシージャが悪いと言う人をたくさん読んだことがあります…。しかし、このような複雑なシナリオを検討する場合、この場合はストアドプロシージャの方が適していると思いませんか。
4

1 に答える 1

6

C＃およびADO.Netでそのようなコードを作成するためのベストプラクティスはありますか。C＃では、通常、ADO.Netを使用して同じコードを再作成できます…。しかし、これが唯一の方法ですか、それとも正しい方法ですか？

したがって、あなたの質問に基づいて、データベースアクセスにDapperのようなものを使用する方がはるかに幸せだと思います。Dapperは、ご存じない方のために説明すると、非常に軽量なデータベースアクセスライブラリであり、より複雑なニーズの一部もサポートします（1回のラウンドトリップで複数の結果セットを返し、それらの結果をPOCOクラスに逆シリアル化するなど）。

つまり、Dapperを使用すると、データベースを希望どおりに正確にクエリできる柔軟性があり、途方もなく高速です。

ここで、より具体的な例として、DapperがIDbConnectionインターフェースを拡張するため、どのデータベースを選択するかは重要ではありません。

データベースはまだ完成していません。

簡単にパラメータ化できるため、SQLインジェクションの対象にはなりません。

var parms = new { ID = 1, Bar1 = "Hello" };
var foo = connection.Query<Foo>(
    "SELECT Bar1, Bar2 FROM Foo WHERE ID = @ID AND Bar1 = @Bar1",
    parms);

また、トランザクションをサポートしているため、操作を単一のトランザクションとして管理できます。

var tran = connection.BeginTransaction();
var parms = new { ID = 1, Bar1 = "Hello" };
var foo = connection.Query<Foo>(
    "SELECT Bar1, Bar2 FROM Foo WHERE ID = @ID AND Bar1 = @Bar1",
    parms, tran);

正直なところ、エンティティフレームワークは非常に人気があり、Microsoftは大量の資金を投入していますが、 Dapperを使用した後はもう購入しません。そして、これが理由です。一般的に言えば、データベースを最大限に活用する方がはるかに優れています。Dapperを使用すると、データベースからデータを取得してデータベースに対して実行するために必要なボイラープレートコードを大幅に削減できるメカニズムが提供されます。 ADO.NET。

さて、これはストアドプロシージャの議論に入る良い方法です。

ストアドプロシージャが悪いと言う人をたくさん読んだことがあります…。しかし、このような複雑なシナリオを検討する場合、この場合はストアドプロシージャの方が適していると思いませんか。

ストアドプロシージャは悪くありません。そして、おそらく2つの角度のいずれかから来ていると述べているほとんどの人：

  1. 彼らは時流に乗っているだけです。
  2. それらは、ストアドプロシージャの目的と利点を認識していません。注意してください：私は愚かだとは言いませんでした、私は無知と言いました。

ストアドプロシージャは、一般的な信念にもかかわらず、すばらしい目的を果たします。何よりもまず、実行計画がまとめられます。第二に、それらは簡単にパラメータ化されて、より複雑でマルチレベルのクエリを高速化しますが、ビューと直接SQLはそうではありません。第三に、それらはDBAに対してより簡単に保護されます。

クエリがありました。当時働いていた会社がまったく同じことを考えていたため、直接SQLクエリでした。また、ストアドプロシージャにすることで、パフォーマンスを98％向上させました。これにより、購入する準備ができていた追加のハードウェアで、会社は月に2,000ドル節約できました。

前に述べたように、データベースを使って得意なことをしてください。多くの人がC＃と.NET Frameworkを使用して500,000個のオブジェクトを並べ替えようとしているのを見て、なぜそれが十分に高速でないのか理解できないため、これは失われることが多いと思います。データベースサーバーで並べ替える必要があります。それは本当に得意なことの1つです！

多くの人がトリガーが悪いと言うので、テクノロジーが役に立たず、悪いという道に人々を導いてはいけませんが、正しい理由で使用された場合、それらは完璧です！

于 2013-03-08T15:02:29.300 に答える