根據(jù)定義，XML 元素和屬性的值是區(qū)分大小寫的。例如，如果搜索值為 “Paris” 的 元素，那么不會(huì)找到 “PARIS” 或 “paris”。可以使用 fn:upper-case() 等 XQuery 函數(shù)解決這個(gè)問(wèn)題，但是使用這些函數(shù)時(shí)不能使用 XML 索引，所以性能可能不好。本文解釋如何使用 DB2® pureXML™ 創(chuàng)建不區(qū)分大小寫的數(shù)據(jù)庫(kù)以及讓 XML 查詢和 XML 索引發(fā)揮預(yù)期的作用。用大寫和小寫函數(shù)執(zhí)行不區(qū)分大小寫的搜索

下面的示例幫助您更清楚地理解不區(qū)分大小寫的搜索。清單 1 定義一個(gè)包含一個(gè) INTEGER 列和一個(gè) XML 列的表，并在表中插入 7 行。每行包含一個(gè)小的客戶文檔，其中包含 XML 元素 。

此元素中的值在大小寫方面并不一致。一些值是全大寫的，一些是全小寫的，其他是大小寫混合的（首字母大寫）。如果數(shù)據(jù)來(lái)自不同的應(yīng)用程序，而這些應(yīng)用程序采用不同的大小寫數(shù)據(jù)輸入規(guī)則，就會(huì)出現(xiàn)這種情況。

清單 1. 示例表和數(shù)據(jù)

CREATE TABLE customer (id INTEGER, xmldoc XML);

INSERT INTO customer (id, xmldoc)
VALUES (1,'<Customer id="1"><city>PARIS</city></Customer>'),
       (2,'<Customer id="2"><city>Tokyo</city></Customer>'),
       (3,'<Customer id="3"><city>tokyo</city></Customer>'),
       (4,'<Customer id="4"><city>PARIS</city></Customer>'),
       (5,'<Customer id="5"><city>paris</city></Customer>'),
       (6,'<Customer id="6"><city>Delhi</city></Customer>'),
       (7,'<Customer id="7"><city>Paris</city></Customer>'); 

如果一個(gè)應(yīng)用程序查詢這些 XML 文檔，尋找某一城市的客戶，那么很可能需要不區(qū)分大小寫的搜索。例如，可能希望找到 Paris 的所有客戶，也就是希望獲取第 1、4、5 和 7 行。但是，如果搜索值 “Paris”，那么只會(huì)返回第 7 行。要想獲取所需的所有四行，可以使用 XQuery 函數(shù) fn:upper-case() 把 city 元素值轉(zhuǎn)換為大寫并與 “PARIS” 做比較。清單 2 中的查詢就采用這種方式，它會(huì)返回 Paris 的所有四個(gè)客戶。

清單 2. 選擇 Paris 的客戶

    
SELECT id, XMLCAST( XMLQUERY('$XMLDOC/Customer/city') AS VARCHAR(15)) AS city
FROM customer
WHERE XMLEXISTS('$XMLDOC/Customer[fn:upper-case(city) = "PARIS"]'); 

如果查詢通過(guò)一個(gè)參數(shù)標(biāo)志提供搜索值，那么這個(gè)參數(shù)也應(yīng)該轉(zhuǎn)換為大寫，見 清單 3。這個(gè)參數(shù)標(biāo)志（“?”）的類型為 VARCHAR(15) 并作為變量 “c” 傳遞給 XQuery 謂詞。

清單 3. 使用參數(shù)標(biāo)志選擇客戶

   
SELECT id, XMLCAST( XMLQUERY('$XMLDOC/Customer/city') AS VARCHAR(15)) AS city
FROM customer
WHERE XMLEXISTS('$XMLDOC/Customer[fn:upper-case(city) = fn:upper-case($c)]'
                 PASSING CAST(? AS VARCHAR(15)) AS "c"); 

圖 1 顯示以上示例查詢的輸出。

圖 1. 示例查詢的結(jié)果

如果只查詢少量數(shù)據(jù)，或者查詢還包含其他選擇性謂詞，使得大寫謂詞只應(yīng)用于很小的中間結(jié)果集，那么這種方式效果還不錯(cuò)。問(wèn)題是如果使用包含 fn:upper-case() 函數(shù)的謂詞，就不會(huì)使用 DB2 中的 XML 索引。因此，這種方式不適用于大量數(shù)據(jù)。

要想避免使用 fn:upper-case() 函數(shù)并利用 XML 索引加快查詢，就需要?jiǎng)?chuàng)建不區(qū)分大小寫的數(shù)據(jù)庫(kù)。

創(chuàng)建不區(qū)分大小寫的 DB2 數(shù)據(jù)庫(kù)

DB2 從 Version 9.5 Fixpack 1 開始支持感知地區(qū)的 Unicode 排序規(guī)則。這使我們能夠忽略大小寫和/或重音符號(hào)。要想創(chuàng)建對(duì)于所有字符串比較不區(qū)分大小寫的數(shù)據(jù)庫(kù)，需要使用排序規(guī)則 UCA500R1，見 清單 4。

清單 4. 創(chuàng)建不區(qū)分大小寫的數(shù)據(jù)庫(kù)

   
CREATE DATABASE testdb
USING CODESET UTF-8 TERRITORY US
COLLATE USING UCA500R1_LEN_S2; 

字符串 UCA500R1_LEN_S2 究竟意味著什么？UCA500R1 指定此數(shù)據(jù)庫(kù)使用基于 Unicode 5.0.0 標(biāo)準(zhǔn)的默認(rèn) Unicode Collation Algorithm（UCA）。因?yàn)槟J(rèn)的 UCA 不能同時(shí)覆蓋 Unicode 支持的每種語(yǔ)言的排序規(guī)則序列，所以可以使用可選屬性定制字符的次序。屬性以下劃線（_）分隔。UCA500R1 關(guān)鍵字加上所有屬性構(gòu)成一個(gè) UCA 排序規(guī)則名。

清單 4 中使用的排序規(guī)則名包含兩個(gè)屬性：LEN 和 S2。LEN 是 L（語(yǔ)言）和 EN（英語(yǔ)的 ISO 639-1 語(yǔ)言編碼）的組合。第二個(gè)屬性 S2 指定強(qiáng)度級(jí)別，這決定在字符串排序或比較時(shí)是否考慮大小寫或重音符號(hào)。在 清單 4 中使用強(qiáng)度級(jí)別 2，所以 “PARIS” 和 “paris” 是相等的。下面是其他有效值的示例：

UCA500R1_LEN_S1 導(dǎo)致 "cliche" = "Cliche" = "cliché"

UCA500R1_LEN_S2 導(dǎo)致 "cliche" = "Cliche" < "cliché"

UCA500R1_LEN_S3 導(dǎo)致 "cliche" < "Cliche" < "cliché"

在 DB2 Information Center 中可以找到可以作為 UCA 排序規(guī)則名的所有組合（參見 參考資料）。

在不區(qū)分大小寫的數(shù)據(jù)庫(kù)中查詢 XML 數(shù)據(jù)

因?yàn)榇藬?shù)據(jù)庫(kù)使用排序規(guī)則名 UCA500R1 和強(qiáng)度級(jí)別 2，所以現(xiàn)在可以簡(jiǎn)化前面的查詢，去掉 fn:upper-case() 函數(shù)（清單 5），就像所有數(shù)據(jù)都是大寫的一樣。無(wú)論搜索字符串是 “Paris” 或 “PARIS” 還是其他任何大小寫組合，結(jié)果都是相同的。

清單 5. 選擇 Paris 的客戶

   
SELECT id, XMLCAST( XMLQUERY('$XMLDOC/Customer/city') AS VARCHAR(15)) AS city
FROM customer
WHERE XMLEXISTS('$XMLDOC/Customer[city = "PARIS"]'); 

圖 2. 示例查詢的結(jié)果

如果通過(guò)添加 ORDER BY 子句按提取的 city 值排序，那么結(jié)果集仍然是相同的：PARIS、paris 和 Paris 被當(dāng)作相同的值。

為了高效地查詢此數(shù)據(jù)，尤其是在表中行數(shù)很大的情況下，應(yīng)該用 XPath /Customer/city 創(chuàng)建一個(gè) XML 索引，見 清單 6：

清單 6. 創(chuàng)建 XML 索引

  
CREATE INDEX customer_lang_idx ON test (xmldoc)
       GENERATE KEY USING XMLPATTERN '/Customer/city' AS SQL VARCHAR(15); 

現(xiàn)在，如果用 Visual Explain 或 db2exfmt 解釋此查詢，就會(huì)看到這個(gè)不區(qū)分大小寫的搜索使用了索引：

圖 3. 在不區(qū)分大小寫的數(shù)據(jù)庫(kù)中查詢 Paris 的所有客戶的 Explain Plan

本節(jié)介紹的方法有一個(gè)潛在的缺點(diǎn)：整個(gè)數(shù)據(jù)庫(kù)中所有表中的所有列中的所有數(shù)據(jù)都是不區(qū)分大小寫的。不可能以區(qū)分大小寫的方式處理特定的表或列。要么都區(qū)分大小寫，要么都不區(qū)分。

注意，不區(qū)分大小寫只應(yīng)用于元素和屬性值，而不應(yīng)用于標(biāo)記名本身。XML 標(biāo)記和路徑表達(dá)式仍然是區(qū)分大小寫的。例如，XPath 表達(dá)式 /Customer/city（小寫 “c”）和 /Customer/City（大寫 “C”）是不同的。后者不匹配示例數(shù)據(jù)中的任何元素，因?yàn)槭纠龜?shù)據(jù)中的 元素名是小寫的。

性能

在數(shù)據(jù)庫(kù)中使用定制的排序規(guī)則可能影響查詢性能，因?yàn)樵谶x擇更寬松的 UCA 設(shè)置時(shí)，匹配的字符串?dāng)?shù)量可能會(huì)增加。換句話說(shuō)，在不區(qū)分大小寫的數(shù)據(jù)庫(kù)中，字符串比較的開銷可能會(huì)略微增加。為了查明區(qū)分大小寫的和不區(qū)分大小寫的數(shù)據(jù)庫(kù)之間的性能差異，我們創(chuàng)建了一個(gè)常規(guī)數(shù)據(jù)庫(kù)（區(qū)分大小寫）和一個(gè)不區(qū)分大小寫的數(shù)據(jù)庫(kù)。然后，插入來(lái)自 TPoX 基準(zhǔn)測(cè)試的 20,000 個(gè) CustAcc 文檔并在這兩個(gè)數(shù)據(jù)庫(kù)中對(duì)各種查詢進(jìn)行測(cè)試。

對(duì)于只涉及少量到中等數(shù)量的行的查詢，兩個(gè)測(cè)試數(shù)據(jù)庫(kù)之間的性能差異可以忽略不計(jì)。我們發(fā)現(xiàn)涉及大量行的查詢的性能差異比較大，比如對(duì)所有 20,000 個(gè) XML 文檔進(jìn)行全表掃描并對(duì)每個(gè)文檔比較字符串。在不區(qū)分大小寫的數(shù)據(jù)庫(kù)中，這種查詢花費(fèi)的時(shí)間增加了 5% 到 8%。因此，實(shí)現(xiàn)不區(qū)分大小寫的搜索需要付出的代價(jià)并不大。

結(jié)束語(yǔ)

以不區(qū)分大小寫的方式搜索 DB 2 數(shù)據(jù)有多種方法，比如使用生成的列（請(qǐng)參見 參考資料）。盡管這些方法都適合關(guān)系數(shù)據(jù)，但是不適合查詢 XML 數(shù)據(jù)。以不區(qū)分大小寫的方式處理 XML 數(shù)據(jù)的最佳方法是用定制的 Unicode 排序規(guī)則創(chuàng)建數(shù)據(jù)庫(kù)。這使數(shù)據(jù)庫(kù)中的所有字符串值比較都采用不區(qū)分大小寫的方式，避免妨礙使用 XML 索引和關(guān)系索引。由于不區(qū)分大小寫或重音符號(hào)，會(huì)增加匹配的字符串，但是增加的開銷非常低。

【編輯推薦】

1. Oracle數(shù)據(jù)庫(kù)中段管理的四個(gè)技巧
2. 最簡(jiǎn)單刪除SQL Server中所有數(shù)據(jù)的方法
3. DB 2數(shù)據(jù)庫(kù)性能優(yōu)化技巧詳解