1

したがって、ストアドプロシージャは最適化されており、SQLステートメントをコードに入れてはいけないと言われています。

しかし、必要なクエリやデータベース操作のすべてのタイプに対して10,000のストアドプロシージャを作成したくありません。

だから私はこのようなことを始めました（すべての関数を単一のsprocに入れます）：

CREATE PROCEDURE [dbo].[spTABLENAME]
@Function nvarchar = null,
@ID int = null,
@MoreVariables int = null

AS
BEGIN
    SET NOCOUNT ON;

IF @Function = 'UPDATE'
    BEGIN
        UPDATE UPDATESTUFF WHERE ID = @ID;
    END
ELSE IF @Function = 'INSERT'
    BEGIN
        INSERT INTO TABLENAME (STUFF)
    END
ELSE IF @Function = 'SELECT'
    BEGIN
        SELECT * FROM TABLENAME  WHERE ID= @ID
    END
ELSE IF @Function = 'DELETE'
    BEGIN
        DELETE * FROM TABLENAME WHERE ID = @ID  
    END

終わり

この方法で何か間違ったことがあるかどうか誰かに教えてもらえますか？

4

4 に答える 4

5

単一の「UPSERT」プロシージャを使用することはかなり一般的ですが、データを返す可能性もあるプロシージャは、私には正しくないと感じています...

覚えておくべきもう1つのことは、個々のストアドプロシージャを使用する場合、オールインワンルーチンではメリットが得られない可能性のあるキャッシュプランなどから追加のメリットを得ることができるということです。

于 2012-05-17T15:27:12.610 に答える
1

この種の方法は、ストアドプロシージャを使用する目的と目的を無効にします。

INSERTたとえば、それらがすでに存在するかどうかに応じて、toまたはUPDATEuserを判別できる単一のストアドプロシージャがあることには何の問題もありません。しかし、すべてを実行するための「汎用」ストアドプロシージャがあると、あまり役に立ちません。

私があなたのプロジェクトに取り組む開発者であり、ユーザーを操作するためのデータアクセスクラスを作成したい場合は、次のようなものに出くわしたいと sp_AddUser思いsp_DeleteUserますsp_UpdateUserAddress。

sp_doStuffToUsers

それ自体が私の心に十分な理由です！

于 2012-05-17T15:30:48.380 に答える
1

複数のcrudステートメントは、関連している場合にのみ1つのストアドプロシージャに結合する必要があります。

SQLは手続き型言語の複雑さに悩まされています。それらを大きくしすぎると、最終的には問題になります。

http://en.wikipedia.org/wiki/SQL

于 2012-05-17T15:33:12.237 に答える
-1

SQLをまったく書かないのは正しくないと思います。SQLが小さい限り、コードにSQLを含めることができます。複雑な結合の場合、ビューを作成してコードで使用できます。
クエリが非常に大きい場合、または複数のクエリを実行してデータを取得または構築しようとしている場合は、ストアドプロシージャがオプションです。
とはいえ、SELECT / UPDATE / INSERTをストアドプロシージャにバンドルする必要はありません。これは、読みやすさに影響を与え、ストアドプロシージャの複雑さを増して、メンテナンスの問題を引き起こすためです。

于 2012-05-17T15:26:22.767 に答える