SQL存储过程不会提高查询的性能

Definitely easier to maintain if you put it in a stored procedure. If there's difficult logic involved that will potentially change in the future it is definitely a good idea to put it in the database when you have multiple clients connecting. For example I'm working on an application right now that has an end user web interface and an administrative desktop application, both of which share a database (obviously) and I'm trying to keep as much logic on the database as possible. This is a perfect example of the DRY principle.

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

存储过程的更多优点:

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

存储过程。

如果出现错误或者逻辑稍有变化，您不必重新编译项目。此外，它允许从不同的来源访问，而不仅仅是在项目中编写查询的一个地方。

我不认为维护存储过程更难，你不应该直接在数据库中编写它们，而应该先在单独的文件中编写，然后你可以在任何你需要设置的DB上运行它们。

你列出了2个procs的优点:

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

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

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

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

@Keith

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

存储过程提供了抵御SQL注入攻击的内在保护。

然而，您并没有完全受到保护，因为您仍然可以编写容易受到此类攻击的存储过程(即存储过程中的动态SQL)。