需要更好的选择 - 外部连接 32 次到同一张表答案

【问题标题】：Need a better option - outer joining 32 times to same table需要更好的选择 - 外部连接 32 次到同一张表
【发布时间】：2011-08-23 20:15:38
【问题描述】：

我遇到了一个棘手的 SQL 查询问题，我希望能提供一个优雅的解决方案。我试图避免 32 个左外连接到同一个表。

数据库是 Teradata。

我有一个包含 1400 万条记录和 33 列的表。主键（我们称它为 Trans_Id）和 32 个编码字段（我们称它们为 encoded_1 ... encoded_32）。像这样的：

CREATE SET TABLE BigTable ,NO FALLBACK , NO BEFORE JOURNAL, NO AFTER JOURNAL, CHECKSUM = DEFAULT
     (
      TRANS_ID VARCHAR(20) CHARACTER SET LATIN NOT CASESPECIFIC,
      ENCODED_1 VARCHAR(10) CHARACTER SET LATIN NOT CASESPECIFIC,
      ENCODED_2 VARCHAR(10) CHARACTER SET LATIN NOT CASESPECIFIC,
      ENCODED_3 VARCHAR(10) CHARACTER SET LATIN NOT CASESPECIFIC,
      ...
      ENCODED_32 VARCHAR(10) CHARACTER SET LATIN NOT CASESPECIFIC )
PRIMARY INDEX ( TRANS_ID );

我还有一个包含编码/解码值的表。假设这张表有 100 条记录。

CREATE SET TABLE LookupTable ,NO FALLBACK , NO BEFORE JOURNAL, NO AFTER JOURNAL, CHECKSUM = DEFAULT
     (
      UNIQ_PK { just random numbers }
      ENCODED_VAR VARCHAR(10) CHARACTER SET LATIN NOT CASESPECIFIC,
      DECODED_DESC VARCHAR(50) CHARACTER SET LATIN NOT CASESPECIFIC)
PRIMARY INDEX ( UNIQ_PK );

我想避免像这样讨厌的连接（我使用省略号而不是显示所有 32 个外连接）：

SELECT 
TRANS_ID
, a.ENCODED_1
, b1.DECODED_DESC DECODED_DESC_1
, a.ENCODED_2
, b2.DECODED_DESC DECODED_DESC_2
...
, a.ENCODED_31
, b31.DECODED_DESC DECODED_DESC_31
, a.ENCODED_32
, b32.DECODED_DESC DECODED_DESC_32
FROM BigTable a
LEFT OUTER JOIN LookupTable b1 ON a.ENCODED_1 = b1.ENCODED
LEFT OUTER JOIN LookupTable b2 ON a.ENCODED_2 = b1.ENCODED
...
LEFT OUTER JOIN LookupTable b31 ON a.ENCODED_31 = b31.ENCODED
LEFT OUTER JOIN LookupTable b32 ON a.ENCODED_32 = b32.ENCODED

任何帮助将不胜感激。我感觉外部加入 14M 记录 32 次不是这样做的有效方法！

【问题讨论】：

" 感觉外部加入 14M 记录 32 次不是这样做的有效方法！" - 慢吗？
如果第二个表太小（100 条记录）以至于整个表都可以保存在内存中，那么我看不出有什么方法可以让它变得更好。看起来很糟糕，但真的很慢吗？
您能否详细说明您要达到的目标？你真的要返回 1400 万条记录吗？您正在“左连接”，因为 BigTable 中的某些字段的值不是您的 LookupTable？
为什么要全部查询？我的意思是，你想让所有 1400 万条记录一起查看吗？
它不是特别慢（但它很昂贵 - 32 个全安培，全行扫描）。我并不关心查询的速度，因为我只是担心敲出来有多讨厌。每列都有唯一的名称，没有模式，我没有实习生来做。我需要用于报告和分析的解码文本 - 来自 14M 的样本（和重新采样）将定期采集和分发。

标签： sql join query-optimization teradata

【解决方案1】：

您可以创建一个函数，将 VARCHAR(10) encoded_var 作为参数并返回 VARCHAR(50) decoded_desc，然后您的选择将是这样的：

SELECT TRANS_ID,
     ENCODED_1, somefunc(ENCODED_1) AS DECODED_DESC_1,
     ENCODED_2, somefunc(ENCODED_2) AS DECODED_DESC_2,
     etc.

根据您计划一次返回的行数，这是可行的。

【讨论】：

哦，我喜欢这个，但我不确定如何在 Teradata 中编写 UDF。

【解决方案2】：

如果编码_1、编码_2 等都被用作同一个表的查找键，听起来它们都是“相同的想法”。但我的第一个想法是，在这种情况下，更好的设计是：

big_table (trans_id, var_id, encoded_var)
lookup_table (encoded_var, decoded_desc)

那么查询就变成了：

select trans_id, var_id, encoded_var, decoded_desc
from big_table
join lookup_table on lookup_table.encoded_var=big_table.encoded_var

我不知道这是否是真实的字段名称，或者您是否只是想省略不相关的细节。您可能会在此处遗漏相关详细信息。编码_1 和编码_2 等有什么区别？如果它们是可互换的，则没有理由为它们设置单独的字段。确实，它会导致很多问题。即使存在语义差异，如果它们都使用相同的查找表，它们也必须来自同一个域。

例如，几年前，我开发了一个系统来管理我们组织制作和使用的技术手册。每本手册有 3 名经理。（处理预算和时间表的行政经理，跟踪谁需要副本并确保他们得到副本的库存经理，以及负责实际文本的内容经理。）但他们都来自同一个人员名单，通常，同一个人可能拥有多个角色，或者在不同的手册中可能拥有不同的角色。因此，我们制作了一个包含 id、姓名、电子邮件地址等的“人员”表，然后在基本的手动记录中，我创建了 3 列，一个用于每种经理类型。

这是一个巨大的错误。我应该做的是创建一个单独的表，其中包含手动 ID、经理类型 ID 和人员 ID，然后为 3 种经理类型创建 3 个记录，而不是在一个记录中包含 3 个字段。

为什么？使用三列时，我遇到了您描述的相同问题，尽管规模较小：我必须从手动表连接到人员表三次。诸如“Bob Smith 负责哪些书？”之类的查询。需要一个令人惊讶的复杂查询，例如

select ... whatever ...
from manual
join person p1 on p1.person_id=manual.admin_id
join person p2 on p2.person_id=manual.stockmanager_id
join person p3 on p3.person_id=manual.contentmanager_id
where p1.name='Bob Smith'
 or p2.name='Bob Smith'
 or p3.name='Bob Smith'

如果只有一列，那就很简单了

select ... whatever ...
from manual
join manual_manager on manual_manager.manual_id=manual.manual_id
join person on person.person_id=manual_manager.person_id
where person.name='Bob Smith'"

由于所有的重复，有几次程序员不小心只检查了 2 个字段而不是全部 3 个字段，这并不奇怪。对于 1 个字段，这个错误是不可能的。对于 3 个字段，如果我们添加第 4 种类型的经理，我们将不得不添加另一列，然后更改查看这些字段的每个查询。对于 1 个字段，我们可能不会。等等。

对于 3 个字段，我们需要 3 个索引，并且还有其他性能影响。

我怀疑你也有同样的想法。

如果您的 32 个字段都是完全可互换的，那么该表只需要一个序列号即可生成唯一的 pk。如果它们之间存在一些差异，那么您可以创建一个代码来区分它们。

【讨论】：

并不是说重复的（一组）字段违反了范式 1。
是的。我打算建议他阅读我的书“A Sane Approach to Database Design”，其中解释了规范化和许多其他内容。但是在这样的论坛上做这么不要脸的插件，就太唯利是图了。 :-)

【解决方案3】：

对于初学者，我会将 LookUp 表上的 PI 更改为 Encoded_Var。您已经必须在每个 Encoded_Var 列上重新分配大表才能加入 LookUp 表。为什么还要每次都重新分配 LookUp 表。

你的桌子设计不是更接近的原因是什么

CREATE SET TABLE BigTable ,NO FALLBACK , NO BEFORE JOURNAL, NO AFTER JOURNAL, CHECKSUM = DEFAULT
     (
      TRANS_ID    VARCHAR(20) CHARACTER SET LATIN NOT CASESPECIFIC NOT NULL,
      ENCODED_VAR VARCHAR(10) CHARACTER SET LATIN NOT CASESPECIFIC NOT NULL
UNIQUE PRIMARY INDEX ( TRANS_ID, ENCODED_VAR );

这将在 trans_id 和 encoded_var 之间建立更合适的 1:M 关系。除非有相关的细节被遗漏来解释为什么这不起作用。事实上，如果需要，您可以将此表构建为关系表，并创建另一个表，如下所示：

    CREATE SET TABLE BigTable2 ,NO FALLBACK , NO BEFORE JOURNAL, NO AFTER JOURNAL, CHECKSUM = DEFAULT
         (
          TRANS_ID    VARCHAR(20) CHARACTER SET LATIN NOT CASESPECIFIC NOT NULL,
          OtherData1  VARCHAR(10) CHARACTER SET LATIN NOT CASESPECIFIC NOT NULL,
          OtherData2  SMALLINT NOT NULL,
          ....,
          OtherDataN  VARCHAR(10) CHARACTER SET LATIN NOT CASESPECIFIC NOT NULL
   UNIQUE PRIMARY INDEX ( TRANS_ID );

希望对您有所帮助。

【讨论】：

【解决方案4】：

如果您不想重复编写相同的查询，我建议将其放在视图中。

为了性能，我建议如下：

按照 Rob Paller 的建议，将 LookupTable 上的主索引更改为 ENCODED_VAR。
在 LookupTable 中，添加一条 DECODED_DESC = null 且 ENCODED_VAR = 一些您永远不会使用的值的新记录。更新 BigTable 以将所有 null ENCODED_* 替换为此值。然后，您可以更改查询以使用所有内部联接并获得相同的结果。

【讨论】：

【解决方案5】：

你不能这样吗：

SELECT 
TRANS_ID
, a.ENCODED_1
, CASE a.ENCODED_1 WHEN b.ENCODED THEN b.DECODED_DESC END DECODED_DESC_1
, a.ENCODED_2
, CASE a.ENCODED_2 WHEN b.ENCODED THEN b.DECODED_DESC END DECODED_DESC_2
...
, a.ENCODED_31
, CASE a.ENCODED_31 WHEN b.ENCODED THEN b.DECODED_DESC END DECODED_DESC_31
, a.ENCODED_32
, CASE a.ENCODED_32 WHEN b.ENCODED THEN b.DECODED_DESC END DECODED_DESC_32
FROM BigTable a
 LEFT JOIN LookupTable b ON (
   a.ENCODED_1 = b.ENCODED OR
   a.ENCODED_2 = b.ENCODED OR
   ...
   a.ENCODED_31 = b.ENCODED OR
   a.ENCODED_32 = b.ENCODED
 )

?

我也可能想重写加入条件如下：

...ON b.ENCODED IN (a.ENCODED_1, a.ENCODED_2, ... a.ENCODED_31, a.ENCODED_32)

但我不确定它是否不能比以前的版本慢。实际上，我的猜测是，它确实会变慢，但我仍然会验证这一点。

【讨论】：

【解决方案6】：

我在 Teradata 上也遇到过同样的问题。一位同事告诉我一个优雅的解决方案，使用单个 LEFT OUTER JOIN 和许多 CASE 语句。

但是，您的示例有点令人困惑，因为您要加入一个不存在的列（“LookupTable”中的“ENCODED”列，我认为应该是“ENCODED_VAR”？）。

SELECT     TRANS_ID    
           , a.ENCODED_1    
           , MAX(CASE WHEN b.ENCODED_VAR = a.ENCODED_1
                 THEN b.DECODED_DESC
                 ELSE NULL
             END) DECODED_DESC_1    
           , a.ENCODED_2    
           , MAX(CASE WHEN b.ENCODED_VAR = a.ENCODED_2
                 THEN b.DECODED_DESC
                 ELSE NULL
             END) DECODED_DESC_2    
           ...    
           , a.ENCODED_31    
           , MAX(CASE WHEN b.ENCODED_VAR = a.ENCODED_31
                 THEN b.DECODED_DESC
                 ELSE NULL
             END) DECODED_DESC_31    
           , a.ENCODED_32    
           , MAX(CASE WHEN b.ENCODED_VAR = a.ENCODED_32
                 THEN b.DECODED_DESC
                 ELSE NULL
             END) DECODED_DESC_32    
FROM BigTable a
LEFT OUTER JOIN LookupTable b 
    ON a.ENCODED_1 = b.ENCODED_VAR
    OR a.ENCODED_2 = b.ENCODED_VAR
    ...
    OR a.ENCODED_31 = b.ENCODED_VAR
    OR a.ENCODED_32 = b.ENCODED_VAR
GROUP BY a.TRANS_ID

这确实依赖于 BigTable 中的 ENCODED_n 和 LookupTable 中的 ENCODED_VAR 之间存在 1:1 的关系。

另外，顺便说一句，您不应该在 Teradata 表中使用随机数作为主索引。虽然这将为您提供出色的表分布，但在进行表查找时它将完全没用。如果您为 PI 使用常用连接字段，则数据库可以直接转到存储数据的 AMP。但是，如果没有这个，DBMS 必须每次都进行全表扫描。只要分布仍然合理，您可能会使用 ENCODED_VAR 作为您的 PRIMARY INDEX 并看到性能大大提高。

我希望这有效。我认为这将适用于您的情况。我还没有验证我的代码是否正确，但它与我自己的解决方案非常相似。

【讨论】：