我们大约3年前开始使用COGNOS。我们已经使用了COGNOS 8，现在使用的是COGNOS 10.我们经常被告知使用动态SQL查询而不是使用COGNOS模型非常糟糕，因为它会导致性能问题，IBM不推荐这样做。我们从未遇到过特定于动态SQL的问题，它们的性能与使用该模型的报告一样好。
是否存在特定于动态SQL查询的性能问题或缺点？ IBM真的推荐它们不被使用吗？
据我所知，该模型非常适合于临时报告和不了解SQL的用户。但对于开发人员来说，动态SQL似乎是一个更好的选择，特别是如果他们对COGNOS模型没有任何控制权。 （我们必须要求并记录模型所需的更改）
感谢您的意见/反馈。
答案 0 :(得分：1)
使用动态SQL手动构建查询可能由于多种原因（可扩展性，可维护性，可重用性）而变得更糟，但性能方面它仅受您自己的SQL查询编写能力的限制。这意味着在某些情况下，它比使用Cognos模型更快。使用动态SQL没有速度缺点。
话虽如此，如果你没有利用这个模型，你会遗漏很多Cognos的好处。使用动态SQL可以大大降低您保持一致性，进行广泛更改而无需重写报告以及快速生成新报告的能力。
如果您的环境很小，动态SQL可能会满足您的需求。特别是对于使用与您的其他报告几乎没有关系的表和关系的奇怪的一次性报告。或者，如果有一种特定的方法要强制使用索引，可以使用动态sql实现。
编辑：请务必注意，在检索到数据之前，不会将Report Studio过滤器中建立的条件传递到动态SQL查询中。对于大型数据集，这可能效率极低。要从提示中将条件传递到动态SQL，请使用#prompt（'yourPromptVariableNamehere'）＃或#promptmany（'yourMultiSelectPromptVariablehere'）＃。这是一个经验法则，在cognos之外运行您的Dynamic SQL查询并查看返回的数据量。如果您有一个巨大的销售查询，至少需要在日期或分支上进行过滤，请在提示页面中放置一个提示，强制用户选择特定的日期/期间/日期范围/分支/等。在提示中，使用prompt / promptmany语法将条件添加到Dynamic SQL语句中。提示仍可用作Report Studio查询中的常规过滤器，但如果您使用动态查询而没有提示/提示，则在从数据库返回结果集后，将过滤所有条件。
答案 1 :(得分：0)
在性能方面，当您引入动态SQL时，它将无法使用Cognos提供的缓存功能（系统方面）。
另一方面，很明显你可以比机器更好地调整SQL。 我不会说动态SQL通常会导致性能问题。
IBM并不推荐动态SQL，因为只有使用适当的模型，使用框架管理器构建，您才能使用Cognos的所有功能。