將“插入/更新/刪除/選擇”放入單個存儲過程是否是不好的做法？

Question

因此，我們被告知存儲過程已優化，我們絕不應該將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

結束

有人可以告訴我這種做法是否有誤？

Answer 1

使用單個“ UPSERT”過程是相當普遍的，但是也有可能返回數據的過程對我來說並不適合。

要記住的另一件事是，如果您使用單個存儲的proc，則可以從緩存計划中獲得一些額外的好處，而使用多合一例程可能無法從中受益。

Answer 2

這種破壞了使用存儲過程的目的和目的。

擁有一個存儲的proc並沒有錯，可以確定是否要INSERT或UPDATE用戶，具體取決於是否存在用戶。 但是擁有一個“通用”存儲過程來做所有事情並不是很有幫助。

如果我是一名開發人員來處理您的項目，並且想編寫一個數據訪問類來操縱您的用戶，那么我寧願遇到這些sp_AddUser ， sp_DeleteUser ， sp_UpdateUserAddress等，而不僅僅是：

sp_doStuffToUsers

在我看來，這本身就是一個足夠充分的理由！

Answer 3

相關聯時，您僅應將多個Crud語句組合到一個存儲過程中。

SQL受過程語言復雜性的困擾。 使它們過大最終將成為一個問題。

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

Answer 4

我不完全不編寫SQL是不正確的。 只要SQL小，我們就可以在代碼中包含SQL。 對於復雜的聯接，我們可以創建視圖，然后在代碼中使用它們。
如果查詢很大，或者您試圖通過進行多個查詢來獲取或構建某些數據，則可以選擇存儲過程。
就是說，您不需要將SELECT / UPDATE / INSERT捆綁到存儲過程中，因為它會影響可讀性並增加存儲過程的復雜性，從而導致維護問題。