SELECT、UPDATEを実行するストアドプロシージャを使用して任意の禁忌、INSTERT

Question

私は基本的に私は何のアクションnecesaryを応じて同じSPを実行しています、したがって、すべてのCRUD操作を実行する1つのSP
を使用しています：

例えば

-- for select 
exec USP_ORDER @MODE='S', @ORDER_DATE='2009/01/01' 
-- for update 
exec USP_ORDER @MODE='U', @other_params 
-- for insert 
exec USP_ORDER @MODE='I', @other_params 
-- for delete 
exec USP_ORDER @MODE='D', @ID=100 

私はDBを注文したままにするBuisness Object 1つにつきSPが1つしかありません。 しかし、最近私はパフォーマンスの問題を経験しました。 それに照らして私の質問：
このアプローチは正しいですか？それはパフォーマンス/適切なエグゼクティブに影響を及ぼしますか？計画？

Answer 1

「間違った」クエリプランをキャッシュする可能性があるため、パフォーマンスに影響を与える可能性があります。トピック'parameter sniffing'とquery plan cachingをチェックしてください。

EDIT：Johnのコメントに応じて、どのCRUD SPを呼び出すかをトップレベルSPに決めさせてから、それぞれ独自のキャッシュされたクエリプランを取得することもできます。

Answer 2

これはコーディング/デザインの好みの質問です。

個人的に、私は物事を単純に保つのが大好きです。このような理由から、私はあなたの操作を別のストアドプロシージャに分解することを提案します。

これはより透明性が高く、今後のパフォーマンスチューニングにも役立ちます。つまり、更新手順/ロジックがゆっくりと実行されている場合は、すぐに原因として分離することができます。さまざまなCRUD操作ではるかに大きな手順であるため、問題の根本的な原因はあまり明確ではありません。

Answer 3

私はまた、単純化のファンです（可能な場合）。

しかし、私はそのように決めた理由：私はすべての彼らは（例えばUSP_Sample_Insert、USP_Sample_Select1、USP_Sample_Select2、 USP_Sample_Delete）の役割を果たす機能で割る場合は、現在私は〜80個のSPを持って、私は〜400のSPを持つことになります！

SPインスタンスが私にとって悪夢である場合、このような膨大な量の間でパラメータを管理、移動、更新、同期します。私にとって

- それを行うための唯一の合理的な場合は、パフォーマンス....