即时查询与存储过程vs动态SQL。任何人都可以说利弊
解决方法
存储程序
> Pro：对于简单的查询(也称为OLTP – 即添加，更新，删除，查看记录)
Pro：保持数据库逻辑与业务逻辑分离
> Pro：易于排除故障
> Pro：易于维护
> Pro：通过网络传输的比特数较少(即只有proc名称和params)
> Pro：在数据库中编译
> Pro：更好的安全性(用户不需要直接访问表)
> Pro：优秀的查询计划缓存(适用于OLTP查询 – 从计划重用中获益)
> Con：优秀的查询计划缓存(OLAP查询不好 – 来自独特计划的好处)
Con：让你绑定到那个SQL供应商
动态SQL(即在存储过程中使用exec命令)
> Pro：好的简单的查询(又名OLTP)
Pro：保持数据库逻辑与业务逻辑分离
> Pro：通过网络传输的比特数较少(即只有proc名称和params)
> Pro：允许引用任何表，数据库或列
> Pro：允许根据参数添加/删除谓词(在WHERE子句中)
> Pro：良好的查询计划缓存(对于OLTP和OLAP查询都是平庸的)
> Con：只能编译proc的静态元素
Con：让你绑定到那个SQL供应商
> Con：更难解决
Con：更容易受到SQL注入攻击
Ad Hoc SQL(即在您的业务代码中创建)
> Pro：对于长时间的复杂结果(也称为OLAP – 即报告或分析)
> Pro：灵活的数据访问
> Pro：ORM使用是可能的;可以在代码中编译/测试(即Linq-to-Sql或SqlAlchemy)
> Pro：查询计划缓存较差(对OLAP查询有利 – 来自独特计划的好处)
> Con：查询计划缓存较差(OLTP查询不好 – 从计划重用中获益)
> Con：通过网络传输更多位(即整个查询和参数)
> Con：更难维护，如果不使用ORM
> Con：更难以排除故障，如果不使用ORM
Con：更容易受到SQL注入攻击
注意：始终参数化您的临时SQL。
对于OLAP特设SQL：仅参数化字符串数据。这满足两个条件。它可以防止SQL注入攻击。而且这使查询看起来对数据库更加独特。是的，你会得到一个很差的查询计划缓存命中率。但是，这对于OLAP查询是可取的。它们受益于独特的计划生成，因为它们的数据集和最有效的计划在给定的参数之间差异很大。 （编辑：李大同）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
