将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注入攻击呈上升趋势。有人很容易找到这些代码并在你的网站上运行注入攻击。您必须始终始终将查询参数化。最好不要在动态SQL查询上运行exec(@x)。在我看来,使用内联SQL并不是一个好主意。
有些人认为,存储过程很麻烦,因为它们是另一组需要与代码分开维护的项。但是它们是可重用的,如果你在查询中发现了一个错误,你可以在不重新编译的情况下修复它们。
其他回答
这样想
你有4个web服务器和一堆使用相同SQL代码的windows应用程序 现在您意识到SQl代码有一个小问题 所以你宁愿...... 在一个地方改变过程 或 将代码推送到所有的网络服务器上,重新安装所有Windows盒子上的所有桌面应用程序(单击一次可能会有帮助)
我更喜欢存储过程
它也更容易做一个过程的性能测试,把它放在查询分析器 设置io/time on统计信息 设置showplan_text,瞧
不需要运行分析器来查看到底调用了什么
这只是我的小意思
在我看来,你不能在这个问题上投赞成票或反对票。这完全取决于应用程序的设计。
我完全反对在三层环境中使用sp,在这种环境中,前端是应用服务器。在这种环境中,应用服务器用于运行业务逻辑。如果你额外使用sp,你就开始在整个系统中分配业务逻辑的实现,谁负责什么就会变得非常不清楚。最终你将得到一个基本上只会做以下事情的应用服务器:
(Pseudocode)
Function createOrder(Order yourOrder)
Begin
Call SP_createOrder(yourOrder)
End
因此,最终你的中间层运行在这个非常酷的4个服务器集群上,每个服务器都配备了16个cpu,实际上它什么都不会做!太浪费了!
如果你有一个臃肿的gui客户端,直接连接到你的数据库或甚至更多的应用程序,这是一个不同的故事。在这种情况下,SPs可以充当某种伪中间层,将应用程序与数据模型解耦,并提供可控的访问。
在我工作的地方,sproc的最大优势是我们有更少的代码移植到VB。NET(来自VB6)。而且它的代码更少,因为我们对所有的查询都使用了spprocs。
当我们需要更新查询而不是更新VB代码,重新编译并在所有计算机上重新安装它时,它也有很大的帮助。
I'm firmly on the side of stored procs assuming you don't cheat and use dynamic SQL in the stored proc. First, using stored procs allows the dba to set permissions at the stored proc level and not the table level. This is critical not only to combating SQL injection attacts but towards preventing insiders from directly accessing the database and changing things. This is a way to help prevent fraud. No database that contains personal information (SSNs, Credit card numbers, etc) or that in anyway creates financial transactions should ever be accessed except through strored procedures. If you use any other method you are leaving your database wide open for individuals in the company to create fake financial transactions or steal data that can be used for identity theft.
存储的proc也比从应用程序发送的SQL更容易维护和性能调优。它们还允许dba查看数据库结构更改对数据访问方式的影响。我从未遇到过允许动态访问数据库的优秀dba。
当存储过程被用于应用程序和数据库之间时,它们是最糟糕的。上面提到的使用它们的许多原因都可以由视图更好地处理。
有关安全的论点是站不住脚的。它只是将安全问题从应用程序转移到数据库。代码就是代码。我曾见过一些存储过程从应用程序中获取SQL,并使用它构建容易受到SQL注入攻击的查询。
一般来说,它们往往会在所谓的数据库开发人员和所谓的应用程序开发人员之间造成裂痕。实际上,所有编写的代码都是应用程序代码,只是执行上下文的不同。
使用丰富的SQL生成库,如LINQ, Rails ActiveRecord或Hibernate/NHibernate,使开发更快。在混合中插入存储过程会降低速度。