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