我正在使用Cognos 10.1，并且有一个报告使用两个具有相同主键的查询。
查询1:UniqueIds
查询2:DetailedInfo
我不确定如何判断使用带有在(UniqueIds.PrimaryKey)中显示PrimaryKey的过滤器的DetailedInfo查询来构建报表是否更好，还是我应该创建第三个将UniqueIds与PrimaryKey上的DetailedInfo连接的查询。
我是Cognos的新手，正在学习不同的想法。使用MicroSoft SQL Server，我只使用内部联接。
所以我的问题是，在Cognos 10.1中哪种方法更好，如何分辨性能差异？
最佳答案
报表编写者的最终武器是索引良好的数据仓库，并在其顶部构建可靠的框架模型。
您希望所有过滤和连接都尽可能在数据库端进行。如果不是，那么大数据集将被带到Cognos服务器，然后再由Cognos合并和过滤。
在数据库上进行的工作越多，您的报告将越快。通过以某些方式构建报告，可以减轻Cognos方面的处理，并促进数据库方面的处理。
正如Alexey所指出的，第一个也是最好的方法是使用好的框架模型。这将使您的报告更简单，并将大部分工作推到数据库中。
但是，一个好的模型仍然可以向报表作者公开表键，以便他们可以灵活地创建唯一的数据集。并非每个报告都需要一个新的Star Schema，有时您希望将针对两个不同Star Schema源的查询结果合并在一起。
使用联接或过滤器时，Cognos会默认尝试将所有工作推送到数据库。它希望将最终数据集发送给它，而别无其他。
但是，在创建过滤器时，您可以通过两种方式来定义变量...使用显式名称来引用建模数据源(即[Presentation View]。[Sales]。[Sales Detail]。[Net Profit])或通过引用到当前数据集中的一列(例如[Net Profit])。使用模型中的显式列将有助于确保将过滤器应用于数据库。
有时这是不可能的，例如使用计算列。例如，如果您的数据库或模型中没有净利润，则可以使用“计算所得”列进行建立。如果在[Net Profit]> 1000上进行过滤，则Cognos将在应用过滤器之前将数据集拉入Cognos。您的最终结果将是相同的，但是根据应用过滤器前后的数据大小，性能可能会下降。
报表中可能有嵌套查询，并且cognos会为最高级别的查询生成一条巨型SQL语句，其中包括所有较低级别数据的子查询。您可以生成SQL / MDX，以查看Cognos如何构建查询。
另外，尝试进行实验。使用新名称保存您的报告，以一种方式尝试并安排时间。运行几次，以平均的执行速度。使用替代方法再次计时并进行比较。
对于较小的数据集，您不太可能看到任何差异。数据集越大，您的方法对报告速度的影响就越大。
关于cognos - 使用Cognos 10.1更好的是内部联接还是“IN”过滤器？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/32595067/