> 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查询是可取的。它们受益于独特的计划生成，因为它们的数据集和最有效的计划在给定的参数之间差异很大。