将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的优点:
性能 安全
当前回答
我参加的Microsoft TechEd安全会议的建议之一是,通过存储过程进行所有调用,并拒绝直接访问表。这种方法被宣传为提供额外的安全性。我不确定仅仅为了安全性是否值得这样做,但如果您已经在使用存储过程,那么这样做也无妨。
其他回答
你列出了2个procs的优点:
性能——不完全是。在Sql 2000或更高版本中,查询计划优化非常好,并被缓存。我相信甲骨文等公司也在做类似的事情。我不认为有什么理由再用scprocs来衡量业绩了。
安全?为什么scprocs会更安全?除非您有一个非常不安全的数据库,否则所有的访问都将来自dba或通过应用程序。总是参数化所有的查询-永远不要内联用户输入的东西,你会没事的。
无论如何,这是性能的最佳实践。
Linq绝对是我现在进行一个新项目的方式。请看这篇类似的文章。
存储过程的优点 1).提高安全性,因为存储过程中的SQL本质上是静态的(大多数)。这将防止SQL注入。 2)。可重用性。如果需要为多个应用程序/组件返回相同的数据,这可能是一个更好的选择,而不是重复SQL语句。 3).减少客户端与数据库服务器之间的调用。
我不确定其他数据库,但您可以在大型机上的db2中使用主机语言创建存储过程,这使得它们非常强大。
存储过程的优先级,因为: 在系统运行时修复一些生产中与数据相关的问题(这对我来说是第一个) - DB和程序之间清晰的契约定义(清晰的关注点分离) -更好的可移植性到不同的DB供应商(如果写得好,代码更改通常只在SP端)。 -更好地进行性能调优
缺点:WHERE子句在使用条件上有很大的变化,需要高性能。
Something that I haven't seen mentioned thus far: the people who know the database best aren't always the people that write the application code. Stored procedures give the database folks a way to interface with programmers that don't really want to learn that much about SQL. Large--and especially legacy--databases aren't the easiest things to completely understand, so programmers might just prefer a simple interface that gives them what they need: let the DBAs figure out how to join the 17 tables to make that happen.
话虽如此,用于编写存储过程的语言(PL/SQL就是一个臭名昭著的例子)是相当残酷的。它们通常不提供您在当今流行的命令式语言、OOP或函数式语言中看到的任何细节。认为COBOL。
因此,请坚持使用仅抽象了关系细节的存储过程,而不是那些包含业务逻辑的存储过程。
这样想
你有4个web服务器和一堆使用相同SQL代码的windows应用程序 现在您意识到SQl代码有一个小问题 所以你宁愿...... 在一个地方改变过程 或 将代码推送到所有的网络服务器上,重新安装所有Windows盒子上的所有桌面应用程序(单击一次可能会有帮助)
我更喜欢存储过程
它也更容易做一个过程的性能测试,把它放在查询分析器 设置io/time on统计信息 设置showplan_text,瞧
不需要运行分析器来查看到底调用了什么
这只是我的小意思