@Keith

安全?为什么scprocs会更安全?

正如Komradekatz所建议的，您可以禁止访问表(对于连接到DB的用户名/密码组合)，而只允许SP访问。这样，如果有人获得了数据库的用户名和密码，他们可以执行SP，但不能访问表或数据库的任何其他部分。

(当然，执行scproc可以给他们所有他们需要的数据，但这将取决于可用的scproc。给他们访问表的权限，他们就能访问所有东西。)

在我看来，你不能在这个问题上投赞成票或反对票。这完全取决于应用程序的设计。

我完全反对在三层环境中使用sp，在这种环境中，前端是应用服务器。在这种环境中，应用服务器用于运行业务逻辑。如果你额外使用sp，你就开始在整个系统中分配业务逻辑的实现，谁负责什么就会变得非常不清楚。最终你将得到一个基本上只会做以下事情的应用服务器:

(Pseudocode)

Function createOrder(Order yourOrder) 
Begin
  Call SP_createOrder(yourOrder)
End

因此，最终你的中间层运行在这个非常酷的4个服务器集群上，每个服务器都配备了16个cpu，实际上它什么都不会做!太浪费了!

如果你有一个臃肿的gui客户端，直接连接到你的数据库或甚至更多的应用程序，这是一个不同的故事。在这种情况下，SPs可以充当某种伪中间层，将应用程序与数据模型解耦，并提供可控的访问。

我参加的Microsoft TechEd安全会议的建议之一是，通过存储过程进行所有调用，并拒绝直接访问表。这种方法被宣传为提供额外的安全性。我不确定仅仅为了安全性是否值得这样做，但如果您已经在使用存储过程，那么这样做也无妨。

CON

我发现在存储过程中进行大量的处理会使您的DB服务器在扩展您的行为时成为一个单一的不灵活点。

然而，如果您有多个服务器运行您的代码，那么在您的程序中进行所有这些处理而不是sql-server，可能会允许您进行更多的扩展。当然，这并不适用于只进行正常获取或更新的存储procs，而是适用于执行更多处理(如在数据集上循环)的存储procs。

PROS

Performance for what it may be worth (avoids query parsing by DB driver / plan recreation etc) Data manipulation is not embedded in the C/C++/C# code which means I have less low level code to look through. SQL is less verbose and easier to look through when listed separately. Due to the separation folks are able to find and reuse SQL code much easier. Its easier to change things when schema changes - you just have to give the same output to the code and it will work just fine Easier to port to a different database. I can list individual permissions on my stored procedures and control access at that level too. I can profile my data query/ persistence code separate from my data transformation code. I can implement changeable conditions in my stored procedure and it would be easy to customize at a customer site. It becomes easier to use some automated tools to convert my schema and statements together rather than when it is embedded inside my code where I would have to hunt them down. Ensuring best practices for data access is easier when you have all your data access code inside a single file - I can check for queries that access the non performant table or that which uses a higher level of serialization or select *'s in the code etc. It becomes easier to find schema changes / data manipulation logic changes when all of it is listed in one file. It becomes easier to do search and replace edits on SQL when they are in the same place e.g. change / add transaction isolation statements for all stored procs. I and the DBA guy find that having a separate SQL file is easier / convenient when the DBA has to review my SQL stuff. Lastly you don't have to worry about SQL injection attacks because some lazy member of your team did not use parametrized queries when using embedded sqls.

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

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

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

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

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

我还没有找到一种在源代码控制中轻松维护存储过程的好方法，使其与代码库一样无缝。这是不会发生的。仅这一点就使得在代码中添加SQL对我来说是值得的。在现代系统中，性能差异可以忽略不计。