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