私はネストされたセットモデルのカテゴリを管理するテーブルを持っていて、新しい各行挿入時に、テーブル全体を更新する必要があります。それがより良いかどうどちらの行が高速に挿入されますか：SQL ServerストアドプロシージャまたはC＃サーバーのサイドコード？
パフォーマンスの問題については、私が知りたい：
OR
この質問に対する正解はありません。一般に、ストアドプロシージャに含まれるコードは、ADO.NETのコードよりも高速です。
つまり、ストアドプロシージャとトリガには実行計画がキャッシュされています（ADO.NETからのアドホッククエリも同様ですが、動作が少し異なります）。実行計画は、基本的に、SQLサーバーが結合操作を実行するために使用するアルゴリズムのロードマップです。ストアドプロシージャまたはトリガが複雑になるにつれて、実行計画がより複雑になります。単一の複合ストアドプロシージャは、渡されたパラメータに応じて、複数の実行プランで終了することもあります。 ストアドプロシージャが非常に複雑になったときに起こることは、SQLサーバーが実際にひどく機能する準最適な実行計画の選択を開始し、コードが突然非常に遅くなる可能性があることです。これが起こると、ADO.NETコードは通常、1つの大きな実行計画ではなく複数の小さな実行計画を含むため、より高速になります。
一般的に、あなたのような状況がある場合、私はいくつかのことを行うストアドプロシージャを使用することを選択します。ビジネス要件が変化し、ストアドプロシージャが長くなったり長くなったりするにつれて更新が増えれば、そのプロシージャを複数のプロシージャに分割することをお勧めします。
私はトリガーを完全にスキップします。トリガーは、システムについて推論することを非常に困難にします。彼らはデバッグすることがほとんど不可能であり、あなたが驚きのために設定したのは、道のりです。
行が挿入されたときにテーブル全体を更新する必要があります。これらの挿入が頻繁に行われている場合は、パフォーマンスの問題がひどくなります。可能であれば、データを正常化して、これを行う必要はありません。
'ストアドプロシージャに含まれるコードの方がADO.NETのコードより高速です。これは決して真実ではありません。実行はまったく同じ手順を踏み、パフォーマンスは同じになります。唯一の引数は、より長いSQL文字列を送信するのに数マイクロ秒かかることです。 – usr
ありがとうございます。残念なことに、入れ子セットモデルのロジックは非常に動的です。通常の階層型ツリーモデルよりも書き込みには負荷がかかりますが、読み込み速度は速くなります。 – Mikahel
私はストアドプロシージャがより速いと主張していません。それらは超複雑であるために遅くなるまで、データベースへのラウンドトリップを減らすので、より高速です。 –
私はそれをSQLで行う方が速くなると思います。これは旅行が少なくなるためです。しかし、100％のために言うことはできません。 – Tim
多くの行を挿入する場合は、C＃でBulkInsertを検討することをお勧めします。 – Shyju
ストアドプロシージャを使用する主な利点は、c＃からID番号を作成するときに不可能な、各行に一意のIDを追加できることです。 SQLサーバーがNetライブラリーよりもSQLストリングを解析する方が効率的であるため、ストアード・プロシージャーは通常より高速です。 – jdweng