将SQL保存在c#源代码或Stored Procs中有哪些优点/缺点?我一直在和一个朋友讨论这个问题,我们正在做一个开源项目(c# ASP。网论坛)。目前,大多数数据库访问都是通过在c#中构建内联SQL并调用SQL Server DB来完成的。所以我在试着确定,对于这个特定的项目,哪个是最好的。

到目前为止,我有:

in Code的优点:

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

存储Procs的优点:

性能 安全


当前回答

我喜欢存储过程,不知道有多少次我能够使用存储过程对应用程序进行更改,而不会对应用程序产生任何停机时间。

作为Transact SQL的忠实粉丝,调优大型查询已被证明对我非常有用。我已经6年没有写过任何内联SQL了!

其他回答

较小的日志

存储过程的另一个小优点是没有提到的:当涉及到SQL流量时,基于sp的数据访问产生的流量要少得多。当您监视流量进行分析和分析时,这一点变得非常重要——日志将会更小且可读。

目前在这里的其他几个线程中正在讨论这个问题。我一直是存储过程的支持者,尽管有一些很好的论据支持Linq to Sql。

在代码中嵌入查询将您与数据模型紧密地结合在一起。存储过程是一种很好的契约式编程形式,这意味着DBA可以自由地更改过程中的数据模型和代码,只要存储过程的输入和输出所表示的契约得到维护。

当查询隐藏在代码中,而不是在一个易于管理的中心位置时,调优生产数据库可能会非常困难。

这里是另一个当前的讨论

坚定地站在“存储过程不利于CRUD/业务逻辑使用”的阵营。我了解在报告、数据导入等方面的需求

写在这里…

使用你的应用程序代码,因为它最擅长:处理逻辑。 使用数据库来做它最擅长的事情:存储数据。

您可以调试存储过程,但是您会发现在代码中调试和维护逻辑更容易。 通常,每次更改数据库模型时,都需要重新编译代码。

此外,具有可选搜索参数的存储过程是非常不有效的,因为您必须预先指定所有可能的参数,而复杂的搜索有时是不可能的,因为您无法预测一个参数将在搜索中重复出现多少次。

我更喜欢把它们保存在代码中(使用ORM,而不是内联或特别),这样它们就可以被源代码控制覆盖,而不必保存.sql文件。

此外,存储过程本身并不更安全。使用sproc可以像使用内联一样轻松地编写糟糕的查询。参数化内联查询与sproc一样安全。