动态SQL与使用模型

Question

我们大约3年前开始使用COGNOS。我们使用了COGNOS 8，现在使用了COGNOS 10。我们经常被告知，使用动态SQL查询而不是使用COGNOS模型是非常糟糕的，因为它会导致性能问题，而且IBM不推荐使用它。我们从来没有遇到过特定于动态SQL的问题，它们的性能与使用模型的报告一样好。

是否存在特定于动态SQL查询的性能问题或缺陷？IBM真的建议不要使用它们吗？

我理解这个模型对于临时报告和不了解SQL的用户来说是很好的。但是对于开发人员来说，动态SQL似乎是一个更好的选择，特别是如果他们对COGNOS模型没有任何控制权的话。(我们必须请求并记录所需的更改模型)

感谢你的评论/反馈。

Answer 1

使用动态SQL手动构建查询可能会因为许多原因(可扩展性、可维护性、可重用性)而更糟，但就性能而言，它仅受您自己的SQL查询编写能力的限制。这意味着在某些情况下，它将比使用Cognos模型更快。使用动态SQL没有速度上的缺点。

尽管如此，如果你没有利用这个模型，那么你就失去了Cognos的很多好处。动态SQL将严重削弱您维护一致性、在不重写报表的情况下进行广泛更改以及快速生成新报告的能力。

如果您的环境很小，动态sql可能会满足您的需要。特别是对于使用与其他报表无关的表和关系的奇数一次性报告。或者，如果您希望强制使用索引的特定方式，这可以通过动态sql实现。

编辑:需要注意的是，在Report筛选器中建立的标准在检索数据之前不会传递到动态SQL查询中。对于大型数据集，这可能是非常低效率的。为了从提示中将条件传递到动态SQL中，请使用#yourPromptVariableNamehere(‘yourPromptVariableNamehere’)#或经验法则是，在cognos之外运行动态SQL查询，查看返回了多少数据。如果您有一个巨大的销售查询，至少需要在日期或分支上进行筛选，则在提示页中放置提示符，以强制用户在提示中选择特定的日期/期间/日期范围/分支/等等，并使用提示/提示多语法将这些条件添加到动态SQL语句中。提示仍然可以用作Report查询中的常规筛选器，但如果您使用的是动态查询而没有提示/提示，则在从数据库返回结果集之后，将对所有这些条件进行筛选。

Answer 2

在性能方面，当您引入动态SQL时，它将无法使用Cognos提供的缓存功能(系统智能)。

另一方面，很明显，您可以比机器更好地调优SQL。我不会说动态SQL一般会导致性能问题。

IBM不推荐动态SQL，因为只有使用适当的模型，使用框架管理器构建，才能使用Cognos的所有特性。