Question

因此我们被告知Stored Procs已经过优化，我们不应该将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

END

有人可以通过这种方式告诉我是否有任何错误吗？

Answer 1

使用单个“UPSERT”程序是相当常见的，但也可能会返回数据的程序对我来说感觉不对...

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

Answer 2

这种做法违背了使用存储过程的要点和目的。

单个存储过程可以确定用户是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捆绑到存储过程中，因为它会影响可读性并增加存储过程的复杂性，从而导致维护问题。

将Insert / Update / Delete / Select放入单个存储过程是不好的做法？

4 个答案: