使用Cognos10.1哪一个更好的内部连接或"IN“过滤器？

Question

我使用的是Cognos10.1，我有一个报表，它使用两个查询，每个查询具有相同的主键。

查询1: UniqueIds

查询2: DetailedInfo

我不知道如何更好地使用DetailedInfo查询构建报表，过滤器上写着PrimaryKey in (UniqueIds.PrimaryKey)，还是应该创建将UniqueIds与DetailedInfo on PrimaryKey连接起来的第三个查询。

我对Cognos并不熟悉，我正在学习不同的想法。使用MicroSoft Server，我只需要使用一个内部连接。

所以我的问题是，在Cognos10.1中，哪一种方式更好，如何分辨性能差异？

Answer 1

报告作者的终极武器是一个索引良好的数据仓库，并在上面建立了一个坚实的框架模型。

您希望您的所有筛选和连接尽可能多地发生在数据库端。如果没有，那么在Cognos加入并过滤它们之前，将大数据集带到Cognos服务器。

数据库上的工作越多，报告的速度就越快。通过以某些方式构建报表，可以减轻Cognos端处理，并促进数据库端处理。

第一个也是最好的方法是使用一个好的框架模型，正如Alexey所指出的。这将使您的报告更简单，并将大部分工作推送到数据库。

然而，一个好的模型仍然向报表作者公开表键，以便他们能够灵活地创建唯一的数据集。并不是每个报表都需要一个新的星型架构，有时您希望加入针对两个不同星型架构源的查询结果。

在使用联接或筛选器时，Cognos尝试将所有工作推送到数据库，作为默认操作。它希望将最终的数据集发送给它，而不是其他任何东西。

但是，在创建过滤器时，有两种方法可以定义变量.具有引用模型数据源的显式名称(即。表示View.Sales.Sales Detail.Net利润)或引用当前数据集中的列(例如净利润)。使用来自模型的显式列将有助于确保过滤器在数据库中应用。

有时这是不可能的，例如使用计算的列。例如，如果您的数据库或模型中没有净利润，则可以使用计算列来建立它。如果您对净利润> 1000进行筛选，Cognos将在应用筛选之前将数据集拖到Cognos中。您的最终结果将是相同的，但是根据应用过滤器之前和之后的数据大小，您可能会看到性能下降。

在报表中有嵌套查询是可能的，cognos将为最高级别的查询生成一个巨大的SQL语句，其中包括对所有低级数据的子查询。您可以生成SQL/MDX，以查看Cognos如何构建查询。

还有，试着做实验。用新的名称保存您的报告，以一种方式和时间尝试它。运行几次并取得平均执行速度。用交替的方法重复一次并进行比较。

对于较小的数据集，您不太可能看到任何不同。数据集越大，方法的差异就越大，会影响报告速度。

Answer 2

你最好从头开始。您的查询(我希望查询主题)应该在Framework中，在一个模型中加入。然后，通过将筛选器应用于第一个查询，可以轻松地过滤第二个查询。Report中的联接是最后一个解决方案。

Answer 3

使用联接将两个查询合并在一起，以便可以在报表中使用来自这两个查询的列。使用IN()语法，如果您唯一的愿望是使用每秒中对应的行的存在来过滤一个查询。这就是说，可能会有很多情况，这两种方法将具有相同的性能，这取决于所涉及的行数、索引等。

顺便说一下，在报表中，Cognos只支持不同查询之间的联接和联合。您可以在过滤器中直接引用其他查询，即使没有建立的关系，但我已经看到了这方面的怪癖，就像它在交互运行而不是计划或导出时工作一样。我会避免在报告中这样做。