ry的条件。有人认为它应该出现在where 子句中，实际上，

    在连接之前或在连接之后过滤都不影响结果（当然，根据这个条件和连接条件本身的可选择xìng

    不同，会有不同的xìng能表现）。然而，在使用空值上的条件时，我们别无选择，只有在连接后才

    能做检查。

    外连接有时需要加distinct。实际上，通过外连接或not in()非关联子查询，来检查数据是否存在

    的差异很小，因为连接所使用的字段，正好与比较子查询结果集的字段完全相同。不过，众所

    周知的是，SQL 语言的“查询表达式风格”对“执行模式”影响很大，尽管理论上不是这么说的。

    这取决于优化器的复杂程度，以及它是否会以类似方法处理这两类查询。换言之，SQL 不是真

    正的声明xìng语言（SQL is not a truly declarative language），尽管优化器不断推陈出新改善SQL的

    可靠xìng（reliability）。

    最后提醒一下，应密切注意null，这个舞会扫兴者（party-poopers）经常出现。虽然在in ()子查

    询中，null与大量非空值连接不会对外层查询造成影响，但在使用not in ()子查询时，由内层查

    询返回的null会造成not in()条件不成立。要确保子查询不会返回null并不需要太高的代价，而且

    这么做可以避免许多灾难。

    总结：数据集可以通过各种技巧进行比较，但一般而言，使用外连接和子集合cāo作符更高效。

    当前值

    Current Values

    当我们只对最近或当前值感兴趣时，如何避免使用嵌套子查询或OLAP 函数（两者都引起排序）

    而直接找到适当值，是非常吸引人的设计。如第1章所述，解决该问题的方法之一，就是把每个

    值与某个“截止日期”相关联—— 就像麦片外盒上的“保质期（best before）”一样——并让当前

    值的“截止日期”是遥远的未来（例如公元2999 年12 月31 日）。这种设计存在一些与实际相

    关的问题，下面讨论这些问题。

    使用“固定日期”，确定当前值变得非常容易。查询如下所示：

    select whatever

    from hist_data

    where item_id = scomvalue

    and record_date = fixed_date_in_the future

    接着，通过主键找到正确的记录。（当然，要参照的日期如果不是当前日期，就必须使用子查询

    或OLAP 函数了。）然而，这种方法有两个主要缺点。

    较明显的缺点：chā入新的历史数据之前，先要更新“当前值”（例如今天），接着，将最新“当

    前值”和历史数据一起chā入表中。这个过程导致工作量加倍。更糟的是，关系理论中的主键用于

    识别记录，但具有唯一xìng的(item_id, record_date)却不能作为主键，因为我们会对它做“部分更新

    （partially update）”。因此，必须有一个能让外键参照的代理键（ID字段或序列号），结果程序

    变得更加复杂。大型历史表的麻烦就是，通常它们也经历过高频率