将SQL保存在c#源代码或Stored Procs中有哪些优点/缺点?我一直在和一个朋友讨论这个问题,我们正在做一个开源项目(c# ASP。网论坛)。目前,大多数数据库访问都是通过在c#中构建内联SQL并调用SQL Server DB来完成的。所以我在试着确定,对于这个特定的项目,哪个是最好的。
到目前为止,我有:
in Code的优点:
更容易维护-不需要运行SQL脚本来更新查询 更容易移植到另一个DB -没有pros到移植
存储Procs的优点:
性能 安全
将SQL保存在c#源代码或Stored Procs中有哪些优点/缺点?我一直在和一个朋友讨论这个问题,我们正在做一个开源项目(c# ASP。网论坛)。目前,大多数数据库访问都是通过在c#中构建内联SQL并调用SQL Server DB来完成的。所以我在试着确定,对于这个特定的项目,哪个是最好的。
到目前为止,我有:
in Code的优点:
更容易维护-不需要运行SQL脚本来更新查询 更容易移植到另一个DB -没有pros到移植
存储Procs的优点:
性能 安全
当前回答
较小的日志
存储过程的另一个小优点是没有提到的:当涉及到SQL流量时,基于sp的数据访问产生的流量要少得多。当您监视流量进行分析和分析时,这一点变得非常重要——日志将会更小且可读。
其他回答
@Terrapin - scprocs同样容易受到注射攻击。正如我所说:
总是参数化所有的查询-永远不要内联用户输入的东西,你会没事的。
这适用于sprocs和动态Sql。
我不确定不重新编译你的应用程序是一个优势。我的意思是,在重新上线之前,您已经针对该代码(应用程序和DB)运行了单元测试。
@Guy -是的,你是对的,sproc确实让你控制应用程序用户,这样他们就只能执行sproc,而不是底层的操作。
我的问题是:如果所有人都通过你的应用程序访问它,使用连接和用户只有有限的更新/插入权限等,这个额外的级别是否增加了安全性或额外的管理?
我的观点是后者。如果他们已经破坏了您的应用程序,可以重新编写它,那么他们还有很多其他的攻击可以使用。
如果动态内联代码,Sql注入仍然可以针对这些spprocs执行,所以黄金法则仍然适用,所有用户输入必须始终参数化。
我想再投一票赞成使用存储过程(尽管在维护和版本控制时它们会带来麻烦)作为一种限制对底层表的直接访问以获得更好的安全性的方法。
在安全性方面,存储过程要安全得多。一些人认为,无论如何,所有的访问都将通过应用程序进行。许多人忘记了一件事,即大多数安全漏洞来自公司内部。想想有多少开发人员知道应用程序的“隐藏”用户名和密码?
此外,正如MatthieuF所指出的,由于应用程序(无论是在桌面服务器还是web服务器上)和数据库服务器之间的往返次数减少,性能可以得到很大的提高。
In my experience the abstraction of the data model through stored procedures also vastly improves maintainability. As someone who has had to maintain many databases in the past, it's such a relief when confronted with a required model change to be able to simply change a stored procedure or two and have the change be completely transparent to ALL outside applications. Many times your application isn't the only one pointed at a database - there are other applications, reporting solutions, etc. so tracking down all of those affected points can be a hassle with open access to the tables.
我还将在加分栏中加上检查,以使SQL编程掌握在专门的人员手中,并使sp更容易隔离和测试/优化代码。
我看到的一个缺点是,许多语言不允许传递表参数,因此传递未知的数据值可能很烦人,一些语言仍然无法处理从单个存储过程中检索多个结果集(尽管后者在这方面并不使sp比内联SQL差)。
我不喜欢存储过程
存储过程更易于维护,因为: 你不需要重新编译你的c#应用每当你想改变一些SQL
无论如何,当数据类型发生变化时,或者您想返回一个额外的列时,您都将重新编译它。总的来说,你可以“透明”地从应用程序下面更改SQL的次数是非常少的
您最终会重用SQL代码。
编程语言,包括c#,都有这个神奇的东西,叫做函数。这意味着您可以从多个地方调用相同的代码块!神奇的!然后你可以把可重用的SQL代码放在其中一个,或者如果你想获得真正的高科技,你可以使用一个库来为你做这件事。我相信它们被称为对象关系映射器,现在很常见。
当您试图构建可维护的应用程序时,代码重复是最糟糕的事情!
同意,这就是为什么storedprocs是个坏东西。将代码重构和分解(分解成更小的部分)为函数要比将SQL分解成函数容易得多。SQL块?
你有4个web服务器和一堆使用相同SQL代码的windows应用程序,现在你意识到SQL代码有一个小问题,所以你宁愿......在一个地方改变程序或将代码推送到所有的web服务器,重新安装所有Windows盒子上的所有桌面应用程序(单击一次可能会有帮助)
为什么你的windows应用程序直接连接到中央数据库?这似乎是一个巨大的安全漏洞,因为它排除了服务器端缓存。他们不应该通过网络服务或者类似于你的网络服务器来连接吗?
所以,推出1个新的sproc,或4个新的web服务器?
在这种情况下,推送一个新的sproc更容易,但根据我的经验,95%的“推送更改”影响的是代码而不是数据库。如果那个月你向服务器推送了20个东西,向数据库推送了1个,那么如果你向服务器推送了21个东西,而向数据库推送了0个东西,你几乎不会损失太多。
更容易检查代码。
你能解释一下吗?我不明白。特别是考虑到scproc可能不在源代码控制中,因此不能通过基于web的SCM浏览器访问等等。
更多的缺点:
Storedprocs存在于数据库中,在外界看来,数据库是一个黑盒。简单的事情,比如想把它们放在源代码控制中,就变成了一场噩梦。
还有一个纯粹努力的问题。如果你想向你的CEO证明为什么只花了他们700万美元来建立一些论坛,那么把所有东西都分解成100万个层可能是有意义的,但为每一件小事创建一个存储过程只是额外的无聊工作,没有任何好处。
我不是存储过程的狂热爱好者,但我在一种情况下使用它们:
当查询相当大时,最好将其作为存储过程存储在数据库中,而不是从代码中发送。这样,就不会从应用服务器向数据库发送大量字符串字符,而只发送“EXEC SPNAME”命令。
当数据库服务器和web服务器不在同一个网络上(例如,internet通信)时,这是多余的。即使事实并非如此,太大的压力也意味着大量的带宽浪费。
但是,伙计,管理起来太糟糕了。我尽量避开他们。