使用Cognos 10.1哪个更好的内连接或“IN”过滤器？

Question

我正在使用Cognos 10.1，并且我有一个报告，它使用两个查询，每个查询都使用相同的主键。

查询1：UniqueIds
查询2：DetailedInfo

我不知道如何判断使用DetailedInfo查询构建报告是否更好，并在（UniqueIds.PrimaryKey）中使用过滤器显示PrimaryKey，或者我应该在PrimaryKey上创建将UniqueIds连接到DetailedInfo的第三个查询。

我是Cognos的新手，我正在学习不同的思考方式。使用MicroSoft SQL Server我只使用内连接。

所以我的问题是，在Cognos 10.1中哪种方式更好，如何判断性能差异是什么？

Answer 1

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

Answer 2

报告编写者的终极武器是一个编制良好的索引数据仓库，并在顶部构建了一个坚固的框架模型。

您希望尽可能在数据库端进行所有过滤和加入。如果没有，那么大型数据集将在Cognos服务器加入并过滤之前被带到Cognos服务器。

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

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

然而，一个好的模型仍然会向报表作者公开表键，以便他们可以灵活地创建唯一的数据集。并非每个报告都保证有新的星型模式，有时您希望加入针对两个不同星型模式源的查询结果。

使用连接或过滤器时，Cognos会尝试将所有工作作为默认值推送到数据库。它希望将最终数据集发送给它，而不是其他任何内容。

但是，在创建过滤器时，有两种方法可以定义变量...使用明确的名称来引用建模数据源（即[Presentation View]。[Sales]。[Sales Detail]。[Net Profit]）或者通过引用当前数据集中的列（例如[净利润]）。使用模型中的显式列有助于确保在数据库中应用过滤器。

有时这是不可能的，例如使用计算列。例如，如果您的数据库或模型中没有Net Profit，则可以使用Calculated列建立Net Profit。如果您过滤[净利润]＆gt; 1000，Cognos会在应用过滤器之前将数据集拉入Cognos。您的最终结果将是相同的，但根据应用过滤器之前和之后的数据大小，您可能会看到性能下降。

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

另外，尝试尝试。使用新名称保存报告，单向尝试并计时。运行几次并采用平均执行速度。使用备用方法再次计时并进行比较。

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

Answer 3

使用联接将两个查询合并在一起，以便可以在报告中使用两个查询中的列。如果您希望使用一秒内相应行的存在来过滤一个查询，请使用IN（）语法。也就是说，很可能有很多情况下两种方法都具有同等的性能，具体取决于所涉及的行数，索引等。

顺便说一下，在报告中，Cognos仅支持不同查询之间的联接和联合。您可以直接在过滤器中引用其他查询，即使没有已建立的关系，但我已经看到了这个问题的怪癖，就像交互式运行但未安排或导出时一样。我会避免在报告中这样做。