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

到目前为止,我有:

in Code的优点:

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

存储Procs的优点:

性能 安全


当前回答

我对存储过程的投票;作为接近数据的抽象层,集合高效,可被许多“客户端”(客户端语言)重用。T-SQL语言有点原始(我猜这是SO的大多数c#人都接触过的),但Oracle的PL/SQL与任何现代编程语言不相上下。

至于版本控制,只需将存储过程代码放在版本控制下的文本文件中,然后运行脚本在数据库中创建procs。

其他回答

存储过程的优点:

更容易检查代码。

耦合更少,因此更容易测试。

更容易调谐。

从网络流量的角度来看,性能通常更好——如果您有一个游标或类似的东西,那么就不会多次访问数据库

您可以更容易地保护对数据的访问,删除对表的直接访问,通过procs加强安全性——这也允许您相对快速地找到更新表的任何代码。

如果涉及到其他服务(如Reporting服务),您可能会发现将所有逻辑存储在存储过程中,而不是存储在代码中,并且必须复制它会更容易

缺点:

对开发人员来说更难管理的是:脚本的版本控制:每个人都有自己的数据库吗?版本控制系统是否与数据库和IDE集成在一起?

@Terrapin - scprocs同样容易受到注射攻击。正如我所说:

总是参数化所有的查询-永远不要内联用户输入的东西,你会没事的。

这适用于sprocs和动态Sql。

我不确定不重新编译你的应用程序是一个优势。我的意思是,在重新上线之前,您已经针对该代码(应用程序和DB)运行了单元测试。


@Guy -是的,你是对的,sproc确实让你控制应用程序用户,这样他们就只能执行sproc,而不是底层的操作。

我的问题是:如果所有人都通过你的应用程序访问它,使用连接和用户只有有限的更新/插入权限等,这个额外的级别是否增加了安全性或额外的管理?

我的观点是后者。如果他们已经破坏了您的应用程序,可以重新编写它,那么他们还有很多其他的攻击可以使用。

如果动态内联代码,Sql注入仍然可以针对这些spprocs执行,所以黄金法则仍然适用,所有用户输入必须始终参数化。

我在其他答案中没有发现的一点是:

如果在您的环境中,数据库及其模式是体系结构的核心,应用程序的作用更小,那么更多地使用存储过程可能是有意义的,这可能有助于为所有需要访问DB的应用程序提供一个级别基础,从而减少代码重复(例如,您确定所有访问DB的应用程序都是用c#或其他。net语言编写的吗?)

另一方面,如果应用程序具有更核心的角色,而DB更多地充当应用程序的备份存储,那么减少存储过程的使用并通过提供一个公共持久性层(可能基于ORM工具/框架)来减少代码重复可能是明智的。

在这两种情况下,重要的是不要将DB视为存储过程的方便存储库。将它们保存在版本控制系统的源文件中,并尽可能地尝试自动化它们的部署(这实际上对所有与模式相关的构件都有效)。

我非常支持代码而不是SPROC。第一个原因是保持代码紧密耦合,第二个原因是源代码控制的便利性,而不需要大量自定义实用程序。

在我们的DAL中,如果我们有非常复杂的SQL语句,我们通常将它们作为资源文件,并在需要时更新它们(这也可以是一个单独的程序集,并在每个db中交换,等等……)

这使得我们的代码和sql调用存储在同一个版本控制中,而不会“忘记”运行一些外部应用程序进行更新。

较小的日志

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