查询 4. 规范化的联结
SELECT G1.CITY AS CITY1, G2.CITY AS CITY2
FROM SORTKEY_GERMAN1 AS G1, SORTKEY_GERMAN2 AS G2
WHERE ICU.SORTKEY(G1.CITY, 'LDE_KPHONEBOOK_S1') =
ICU.SORTKEY(G2.CITY, 'LDE_KPHONEBOOK_S1')
ORDER BY G1.CITY 结果 4. 规范化的联结CITY1CITY2
-------------------- --------------------
KölnKoeln
LuebeckLuebeck
NuernbergNürnberg 通过使用排序键（而不是值本身）进行比较，适当地处理了名称中的次要差异。通过选择适当的排序规则，可以根据语言进行比较、忽略大小写和重音差异或者完全忽略某些字符。 在 ORDER BY 子句中，修改一个排序规则的强度来忽略字符属性可能会导致不确定的查询结果次序。例如， ORDER BY ICU.SORTKEY(COLUMN, 'S1') （这里使用的排序规则会忽略大小写和重音）会正确地排列 A < B < C。但是，这个排序规则不区分 “apple、“Apple 和 “APPLE，可能以任意次序返回这些单词。 SORTKEY 产生的值依靠于使用的排序规则。因此，当在谓词中使用 SORTKEY 时，比较的两边要使用完全相同的排序规则。 性能考虑因素 当在查询中引入 UDF 时，它会损害查询的性能。对数据库和查询的设计进行仔细地分析，可以将性能影响最小化。 要考虑的一些因素是： 使用固定的排序规则名 尽可能少使用 SORTKEY 使用生成的列 使用固定的排序规则名 预备要使用的排序规则是一种开销很大的操作。因此，在查询执行时不要改变排序规则名。例如，考虑以下表和查询： 上一页123456789下一页 NAMES: NAMELANGUAGE
------------
BobLEN
MarcLFR
Serge LDE
SELECT NAME FROM NAMES
WHERE ICU.SORTKEY(NAME, LANGUAGE) = ICU.SORTKEY(:hv, LANGUAGE) 在这个例子中，对于每一行都要预备一个新的排序规则。这样做的效率非常低。假如 SORTKEY 的第二个参数替换为一个字面字符串或主机变量，那么查询的性能会好得多。 注重，可以在一个查询中混合使用不同的排序规则，只要每个排序规则在不同的 SORTKEY 实例中。以下查询的性能会好得多：SELECT NAME FROM NAMES
WHERE ICU.SORTKEY(NAME, 'LFR') = ICU.SORTKEY(:hv, 'LFR') 尽可能少使用 SORTKEY 假如知道数据是一致的，那么就不需要对每个操作都使用 SORTKEY。例如，考虑前面的 查询 3 和 查询 4。假如数据是以一致的方式输入的，比如总是使用 ä、ö 和 ü，或者已经对数据进行了清理，将所有 ae、oe 和 ue 替换为 ä、ö 和 ü，那么查询 3 和查询 4 会返回同样的结果，而查询 3 运行得快的多。 假如数据是一致的，就不经常需要 SORTKEY。尽可能使用标准的 SQL 比较操作符，并在最后的 ORDER BY 中使用 SORTKEY。 使用生成的列 假如数据库经常使用很少几个排序规则，那么可以考虑使用生成的列预先计算 SORTKEY 的结果，并将这些结果存储在数据库中。 例如，假设一个数据库通常只需要法语和德语排序规则。在这种情况下，根据表的总规模，可以考虑创建生成的列来保存 SORTKEY 的结果。例如： 清单 3. 创建生成的列来保存 SORTKEY 的结果CREATE TABLE NAMES
(
NAME VARCHAR(50),
NAME_FR_KEY VARCHAR(1200) GENERATED ALWAYS AS (ICU.SORTKEY(NAME, 'LFR')),
NAME_DE_KEY VARCHAR(1200) GENERATED ALWAYS AS (ICU.SORTKEY(NAME, 'LDE'))
)
SELECT NAME FROM NAMES
ORDER BY ICU.SORTKEY(NAME, 'LFR')
