将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可能比存储的proc具有更好的性能。如果您已经创建了一个存储的proc(例如sp_customersearch),它必须非常灵活,因此具有许多参数,非常复杂,那么您可能可以在运行时在代码中生成一个更简单的sql语句。
有人可能会说,这只是将一些处理从SQL转移到web服务器,但总的来说,这是一件好事。
这种技术的另一个优点是,如果你在SQL分析器中查找,你可以看到你生成的查询,调试它比看到一个存储的带有20个参数的proc调用要容易得多。
其他回答
存储过程的性能优势通常可以忽略不计。
存储过程的更多优点:
防止反向工程(当然,如果使用加密创建的话) 更好地集中数据库访问 能够透明地更改数据模型(无需部署新客户端);当多个程序访问相同的数据模型时尤其方便
我对存储过程的投票;作为接近数据的抽象层,集合高效,可被许多“客户端”(客户端语言)重用。T-SQL语言有点原始(我猜这是SO的大多数c#人都接触过的),但Oracle的PL/SQL与任何现代编程语言不相上下。
至于版本控制,只需将存储过程代码放在版本控制下的文本文件中,然后运行脚本在数据库中创建procs。
我还没有找到一种在源代码控制中轻松维护存储过程的好方法,使其与代码库一样无缝。这是不会发生的。仅这一点就使得在代码中添加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万个层可能是有意义的,但为每一件小事创建一个存储过程只是额外的无聊工作,没有任何好处。
存储过程比代码更容易在数据库和源代码控制系统之间失去同步。应用程序代码也可以,但当您进行持续集成时,这种可能性较小。
数据库就是这样,人们不可避免地对生产数据库进行更改,只是为了暂时摆脱困境。然后忘记在环境和源代码控制系统之间同步它。生产数据库迟早会成为事实上的记录,而不是源代码控制系统——您将陷入无法删除任何scprocs的情况,因为您不知道它是否正在被使用。
一个好的过程应该只允许通过适当的渠道对产品进行更改,这样您就能够从源代码控制系统(无数据)从头开始重新构建数据库。但我只是说,因为它可以完成,也确实完成了——在最激烈的时刻,在大喊大叫的客户的电话之间,在紧盯着你的经理的电话之间,等等,对生产数据库进行了更改。
使用存储过程运行特别查询很尴尬——使用动态sql(或ORM)更容易,这可能是我自己使用存储过程的最大缺点。
另一方面,存储过程在你做出更改但不需要重新部署应用程序代码的情况下很好。它还允许您在通过网络发送数据之前对数据进行塑形,而代码中的sql可能必须进行多次调用来检索而不是塑形(尽管现在有方法可以在一次“调用”中运行多个sql语句并返回多个结果集,如ADO.NET中的MARS),这可能会导致更多的数据通过网络传输。
不过,我不相信任何关于性能和安全性的争论。两者都有可能是好的,也有可能是坏的,而且同样可控。