将SQL保存在c#源代码或Stored Procs中有哪些优点/缺点?我一直在和一个朋友讨论这个问题，我们正在做一个开源项目(c# ASP。网论坛)。目前，大多数数据库访问都是通过在c#中构建内联SQL并调用SQL Server DB来完成的。所以我在试着确定，对于这个特定的项目，哪个是最好的。
到目前为止，我有:
in Code的优点:
更容易维护-不需要运行SQL脚本来更新查询 更容易移植到另一个DB -没有pros到移植
存储Procs的优点:
性能 安全
当前回答
对于Microsoft SQL Server，您应该尽可能使用存储过程来帮助执行计划缓存和重用。为什么要优化计划重用?因为生成执行计划的成本相当高。
Although the caching and reuse of execution plans for ad-hoc queries has improved significantly in later editions of SQL server (especially 2005 and 2008) there are still far fewer issues with plan reuse when dealing with stored procedures than there are for ad-hoc queries. For example, SQL server will only re-use an execution plan if the plan text matches exactly - right down to comments and white space, for example, if each of the following lines of SQL were to be executed independently, none of them would use the same execution plan:
SELECT MyColumn FROM MyTable WHERE id = @id
select MyColumn from MyTable WHERE id = @id
SELECT MyColumn FROM MyTable WHERE id = @id
SELECT MyColumn FROM MyTable WHERE id = @id -- "some comment"
SELECT MyColumn FROM MyTable WHERE id = @id -- "some other comment"
除此之外,如果你不显式地指定类型的参数然后有一个好的机会,SQL Server可能出错,例如如果您执行上面的查询与输入4,然后用@ id查询SQL Server将parametrise SMALLINT(或可能是一个非常小的整数),所以如果你然后执行相同的查询@ id的说4000,SQL Server将parametrise INT,而不会重用相同的缓存。
我认为还有其他一些问题，老实说，大多数问题都可以解决——特别是在SQL Server的后续版本中，但是存储过程通常会提供更多的控制。
其他回答
我对存储过程的投票;作为接近数据的抽象层，集合高效，可被许多“客户端”(客户端语言)重用。T-SQL语言有点原始(我猜这是SO的大多数c#人都接触过的)，但Oracle的PL/SQL与任何现代编程语言不相上下。
至于版本控制，只需将存储过程代码放在版本控制下的文本文件中，然后运行脚本在数据库中创建procs。
目前在这里的其他几个线程中正在讨论这个问题。我一直是存储过程的支持者，尽管有一些很好的论据支持Linq to Sql。
在代码中嵌入查询将您与数据模型紧密地结合在一起。存储过程是一种很好的契约式编程形式，这意味着DBA可以自由地更改过程中的数据模型和代码，只要存储过程的输入和输出所表示的契约得到维护。
当查询隐藏在代码中，而不是在一个易于管理的中心位置时，调优生产数据库可能会非常困难。
这里是另一个当前的讨论
对于Microsoft SQL Server，您应该尽可能使用存储过程来帮助执行计划缓存和重用。为什么要优化计划重用?因为生成执行计划的成本相当高。
Although the caching and reuse of execution plans for ad-hoc queries has improved significantly in later editions of SQL server (especially 2005 and 2008) there are still far fewer issues with plan reuse when dealing with stored procedures than there are for ad-hoc queries. For example, SQL server will only re-use an execution plan if the plan text matches exactly - right down to comments and white space, for example, if each of the following lines of SQL were to be executed independently, none of them would use the same execution plan:
SELECT MyColumn FROM MyTable WHERE id = @id
select MyColumn from MyTable WHERE id = @id
SELECT MyColumn FROM MyTable WHERE id = @id
SELECT MyColumn FROM MyTable WHERE id = @id -- "some comment"
SELECT MyColumn FROM MyTable WHERE id = @id -- "some other comment"
除此之外,如果你不显式地指定类型的参数然后有一个好的机会,SQL Server可能出错,例如如果您执行上面的查询与输入4,然后用@ id查询SQL Server将parametrise SMALLINT(或可能是一个非常小的整数),所以如果你然后执行相同的查询@ id的说4000,SQL Server将parametrise INT,而不会重用相同的缓存。
我认为还有其他一些问题，老实说，大多数问题都可以解决——特别是在SQL Server的后续版本中，但是存储过程通常会提供更多的控制。
存储过程。
如果出现错误或者逻辑稍有变化，您不必重新编译项目。此外，它允许从不同的来源访问，而不仅仅是在项目中编写查询的一个地方。
我不认为维护存储过程更难，你不应该直接在数据库中编写它们，而应该先在单独的文件中编写，然后你可以在任何你需要设置的DB上运行它们。
存储过程的优点:
更容易检查代码。
耦合更少，因此更容易测试。
更容易调谐。
从网络流量的角度来看，性能通常更好——如果您有一个游标或类似的东西，那么就不会多次访问数据库
您可以更容易地保护对数据的访问，删除对表的直接访问，通过procs加强安全性——这也允许您相对快速地找到更新表的任何代码。
如果涉及到其他服务(如Reporting服务)，您可能会发现将所有逻辑存储在存储过程中，而不是存储在代码中，并且必须复制它会更容易
缺点:
对开发人员来说更难管理的是:脚本的版本控制:每个人都有自己的数据库吗?版本控制系统是否与数据库和IDE集成在一起?
