1

所以我们被告知存储过程已经过优化，我们永远不应该将 sql 语句放入代码中。

但我不想为我需要的每种查询或数据库操作创建 10,000 个存储过程。

所以我开始做这样的事情（将所有函数放入一个存储过程中）：

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”程序是相当普遍的，但一个也可能返回数据的程序对我来说感觉不合适......

要记住的另一件事是，如果您使用单独的存储过程，您可以从缓存计划中获得一些额外的好处，而您可能无法从一体化程序中受益。

于 2012-05-17T15:27:12.610 回答
1

当它们相关时，您应该只将多个 crud 语句组合到一个存储过程中。

SQL 受过程语言复杂性的影响。使它们太大最终将成为一个问题。

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

于 2012-05-17T15:33:12.237 回答
1

这种方式违背了使用存储过程的意义和目的。

拥有一个可以确定是用户INSERT还是UPDATE用户的存储过程没有任何问题，例如，这取决于它们是否已经存在。但是拥有一个“通用”存储过程来做所有事情并不是很有帮助。

如果我是一名开发人员来处理您的项目并且我想编写一个数据访问类来操作您的用户，我宁愿遇到这些 sp_AddUser,等sp_DeleteUser，sp_UpdateUserAddress而不仅仅是：

sp_doStuffToUsers

在我看来，这本身就是一个足够好的理由！

于 2012-05-17T15:30:48.380 回答
-1

我认为根本不写 SQL 是不正确的。只要 SQL 很小，我们就可以在代码中包含 SQL。对于复杂的连接，我们可以创建视图然后在代码中使用它们。
如果查询非常大，或者您试图通过多次查询来获取或构建一些数据，则可以选择存储过程。
也就是说，您不需要将 SELECT/UPDATE/INSERT 捆绑到存储过程中，因为它会影响可读性并增加存储过程的复杂性，从而导致维护问题。

于 2012-05-17T15:26:22.767 回答