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

到目前为止,我有:

in Code的优点:

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

存储Procs的优点:

性能 安全


当前回答

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

其他回答

程序员希望代码在他们的应用程序中,DBA希望它在数据库中。

如果你两者都有,你可以通过使用存储过程在两者之间分配工作,程序员不必担心所有这些表如何连接在一起等(对不起,我知道你想控制一切。)

我们有一个第三方应用程序,它允许在数据库中的视图或存储过程上创建自定义报告。如果我把代码中的所有逻辑都放在另一个应用程序中,就不能重用它。如果你使用数据库编写所有的应用程序,这不是问题。

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

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

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

这里是另一个当前的讨论

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

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

(Pseudocode)

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

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

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

存储过程更易于维护,因为:

你不需要重新编译你的c#应用每当你想改变一些SQL 您最终会重用SQL代码。

当您试图构建可维护的应用程序时,代码重复是最糟糕的事情!

当您发现需要在多个地方纠正的逻辑错误时会发生什么?您更容易忘记更改复制和粘贴代码的最后一个位置。

在我看来,性能和安全性的提高是一个额外的加分项。您仍然可以编写不安全/低效的SQL存储过程。

更容易移植到另一个DB -没有pros到移植

在另一个DB中创建所有存储过程并不难。事实上,它比导出表更容易,因为不需要担心主键/外键。

在某些情况下,在代码中动态创建的sql可能比存储的proc具有更好的性能。如果您已经创建了一个存储的proc(例如sp_customersearch),它必须非常灵活,因此具有许多参数,非常复杂,那么您可能可以在运行时在代码中生成一个更简单的sql语句。

有人可能会说,这只是将一些处理从SQL转移到web服务器,但总的来说,这是一件好事。

这种技术的另一个优点是,如果你在SQL分析器中查找,你可以看到你生成的查询,调试它比看到一个存储的带有20个参数的proc调用要容易得多。