@Terrapin - scprocs同样容易受到注射攻击。正如我所说:

总是参数化所有的查询-永远不要内联用户输入的东西，你会没事的。

这适用于sprocs和动态Sql。

我不确定不重新编译你的应用程序是一个优势。我的意思是，在重新上线之前，您已经针对该代码(应用程序和DB)运行了单元测试。

@Guy -是的，你是对的，sproc确实让你控制应用程序用户，这样他们就只能执行sproc，而不是底层的操作。

我的问题是:如果所有人都通过你的应用程序访问它，使用连接和用户只有有限的更新/插入权限等，这个额外的级别是否增加了安全性或额外的管理?

我的观点是后者。如果他们已经破坏了您的应用程序，可以重新编写它，那么他们还有很多其他的攻击可以使用。

如果动态内联代码，Sql注入仍然可以针对这些spprocs执行，所以黄金法则仍然适用，所有用户输入必须始终参数化。

Something that I haven't seen mentioned thus far: the people who know the database best aren't always the people that write the application code. Stored procedures give the database folks a way to interface with programmers that don't really want to learn that much about SQL. Large--and especially legacy--databases aren't the easiest things to completely understand, so programmers might just prefer a simple interface that gives them what they need: let the DBAs figure out how to join the 17 tables to make that happen.

话虽如此，用于编写存储过程的语言(PL/SQL就是一个臭名昭著的例子)是相当残酷的。它们通常不提供您在当今流行的命令式语言、OOP或函数式语言中看到的任何细节。认为COBOL。

因此，请坚持使用仅抽象了关系细节的存储过程，而不是那些包含业务逻辑的存储过程。

我通常写OO代码。我猜你们大多数人可能也有同感。在这种上下文中，所有业务逻辑(包括SQL查询)都属于类定义，这在我看来是显而易见的。分割逻辑(部分驻留在对象模型中，部分驻留在数据库中)并不比将业务逻辑放到用户界面中更好。

关于存储过程的安全性优势，在前面的回答中已经说了很多。它们分为两大类:

1)限制直接访问数据。这在某些情况下确实很重要，当你遇到这样的情况时，存储过程几乎是你唯一的选择。然而，根据我的经验，这样的情况是例外而不是规则。

2) SQL injection/parametrized queries. This objection is a red herring. Inline SQL - even dynamically-generated inline SQL - can be just as fully parametrized as any stored proc and it can be done just as easily in any modern language worth its salt. There is no advantage either way here. ("Lazy developers might not bother with using parameters" is not a valid objection. If you have developers on your team who prefer to just concatenate user data into their SQL instead of using parameters, you first try to educate them, then you fire them if that doesn't work, just like you would with developers who have any other bad, demonstrably detrimental habit.)

in Code的优点: 更容易维护-不需要运行SQL脚本来更新查询 更容易移植到另一个DB -没有pros到移植

实际上，我觉得你搞反了。恕我直言，在代码中维护SQL是痛苦的，因为:

你最终会在相关的代码块中重复自己 许多IDE不支持SQL作为一种语言，因此您只有一系列未出错的检查字符串来执行任务 数据类型、表名或约束的更改远比将整个数据库交换为一个新的数据库普遍得多 随着查询复杂性的增加，您的难度级别也在增加 测试内联查询需要构建项目

把Stored Procs看作你从数据库对象中调用的方法——它们更容易重用，只有一个地方可以编辑，而且如果你确实更改了数据库提供程序，更改发生在你的Stored Procs中，而不是在你的代码中。

也就是说，存储过程的性能增益是最小的，正如Stu在我之前说过的，你不能在存储过程中设置断点(目前)。

存储过程的性能优势通常可以忽略不计。

存储过程的更多优点:

防止反向工程(当然，如果使用加密创建的话) 更好地集中数据库访问 能够透明地更改数据模型(无需部署新客户端);当多个程序访问相同的数据模型时尤其方便

你列出了2个procs的优点:

性能——不完全是。在Sql 2000或更高版本中，查询计划优化非常好，并被缓存。我相信甲骨文等公司也在做类似的事情。我不认为有什么理由再用scprocs来衡量业绩了。

安全?为什么scprocs会更安全?除非您有一个非常不安全的数据库，否则所有的访问都将来自dba或通过应用程序。总是参数化所有的查询-永远不要内联用户输入的东西，你会没事的。

无论如何，这是性能的最佳实践。

Linq绝对是我现在进行一个新项目的方式。请看这篇类似的文章。