将SQL保存在c#源代码或Stored Procs中有哪些优点/缺点?我一直在和一个朋友讨论这个问题，我们正在做一个开源项目(c# ASP。网论坛)。目前，大多数数据库访问都是通过在c#中构建内联SQL并调用SQL Server DB来完成的。所以我在试着确定，对于这个特定的项目，哪个是最好的。
到目前为止，我有:
in Code的优点:
更容易维护-不需要运行SQL脚本来更新查询 更容易移植到另一个DB -没有pros到移植
存储Procs的优点:
性能 安全
当前回答
很明显，使用存储过程比在代码中构造SQL有几个优点。
代码实现和SQL变得彼此独立。 代码更容易阅读。 写一次用多次。 修改一次 不需要向程序员提供关于数据库的内部细节。等等，等等。
其他回答
我更喜欢使用O/R映射器，如LLBLGen Pro。
它为您提供了相对轻松的数据库可移植性，允许您使用强类型对象用与应用程序相同的语言编写数据库访问代码，并且在我看来，允许您更灵活地处理所拉回的数据。
实际上，能够使用强类型对象是使用O/R Mapper的充分理由。
在某些情况下，在代码中动态创建的sql可能比存储的proc具有更好的性能。如果您已经创建了一个存储的proc(例如sp_customersearch)，它必须非常灵活，因此具有许多参数，非常复杂，那么您可能可以在运行时在代码中生成一个更简单的sql语句。
有人可能会说，这只是将一些处理从SQL转移到web服务器，但总的来说，这是一件好事。
这种技术的另一个优点是，如果你在SQL分析器中查找，你可以看到你生成的查询，调试它比看到一个存储的带有20个参数的proc调用要容易得多。
目前在这里的其他几个线程中正在讨论这个问题。我一直是存储过程的支持者，尽管有一些很好的论据支持Linq to Sql。
在代码中嵌入查询将您与数据模型紧密地结合在一起。存储过程是一种很好的契约式编程形式，这意味着DBA可以自由地更改过程中的数据模型和代码，只要存储过程的输入和输出所表示的契约得到维护。
当查询隐藏在代码中，而不是在一个易于管理的中心位置时，调优生产数据库可能会非常困难。
这里是另一个当前的讨论
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.
我喜欢存储过程，不知道有多少次我能够使用存储过程对应用程序进行更改，而不会对应用程序产生任何停机时间。
作为Transact SQL的忠实粉丝，调优大型查询已被证明对我非常有用。我已经6年没有写过任何内联SQL了!
