iBATIS使用之高級查詢技術詳解
iBATIS In Action為iBATIS展現(xiàn)自己強大功能提供了保證，iBATIS也可以完成更為復雜的任務。在本章中，我們會了解新的技術，減少我們的編碼量；以及改善性能、降低資源消耗（footprint）的幾種方法。
1 使用iBATIS操作XML
譯者注：iBATIS的Java版本可以操作基于XML的數(shù)據(jù)。但意義并不是很大，在以后的版本中該特性可能會被移除。iBATIS.NET則未提供該功能。
2 使用映射語句關聯(lián)對象
iBATIS框架也提供了多種方法用以關聯(lián)復雜的對象，比如訂單（order）和它的訂單項（order item）（還有它們的相關產(chǎn)品、顧客等等）。每種方法都有其優(yōu)點和缺點，正所謂“尺有所短，寸有所長”，每一種方案都不是完美的。應根據(jù)需要來選擇適合的方案。
注意：為簡短起見，在本章的余下的例子中，我們將省略那些對于演示來說不必要的數(shù)據(jù)。例如，當我們獲取了一個顧客（customer）對象，我們不會獲取它的所有字段，而是僅僅獲取它的主鍵和外鍵。
2.1 復雜的集合屬性
在第4章中，我們學習了如何使用SELECT語句從數(shù)據(jù)庫獲取數(shù)據(jù)。在那些例子中，我們獲取的結果僅僅是單個對象，即使是連接多表也是如此。事實上，如果您有多個復雜對象，也可以使用iBATIS加載它們。
如果我們的應用程序模型與數(shù)據(jù)模型比較類似，那么這個功能會很有用?？梢钥紤]根據(jù)對象的關系（關聯(lián)）來定義數(shù)據(jù)模型，然后使用iBATIS將它們一起加載。例如，如果在數(shù)據(jù)庫中，Account記錄對應著相關的Order記錄，而Order又對應著相關的OrderItem記錄，可以為這些記錄建立關系，當我們請求一條Account記錄時，可以一并獲取所有的Order和OrderItem記錄。下面的代碼清單顯示了如何定義我們的SQL映射：
圖1SQL映射
先來看看結果映射（result map，即上面的ResultAccountInfoMap，ResultOrderInfoMap和ResultOrderItemMap），前兩個Map都用到了select特性。這個特性告訴iBATIS，屬性的值將由另一個映射語句來設置，語句的名稱就是select特性的值。例如，我們執(zhí)行getAccountInfoList語句時，ResultAccountInfoMap結果映射有一個子元素：
圖2select特性的值
它的作用是告訴iBATIS，account對象的orderList屬性的值由ChgetOrderInfoList語句來設置，同時把accountId列的值傳給ChgetOrderInfoList作為參數(shù)。類似地，在設置order對象的orderItemList對象時，也會執(zhí)行getOrderItemList語句。
這個功能給我們帶來便利的同時，也帶來了兩個問題。首先，創(chuàng)建包含大量對象的列表可能會消耗大量的內(nèi)存。其次，這種方法會導致數(shù)據(jù)庫的I/O問題，其原因是所謂的“N+1 Select”現(xiàn)象，這個現(xiàn)象將在后面討論。對于每個問題，iBATIS框架都提供了解決方案，但是注意，沒有哪一種能同時解決這兩個問題。
數(shù)據(jù)庫I/O
數(shù)據(jù)庫I/O是數(shù)據(jù)庫使用狀況的一項指標，也是數(shù)據(jù)庫性能的主要瓶頸之一。在讀取或?qū)懭霐?shù)據(jù)庫時，數(shù)據(jù)必須要經(jīng)歷從磁盤到內(nèi)存或者從內(nèi)存到磁盤的轉換，這個過程是比較耗時的。在程序中使用緩存可以減少對數(shù)據(jù)庫的訪問，但這種方法使用時要謹慎，否則也會引發(fā)問題。要了解iBATIS中的緩存機制，可以參看第10章的內(nèi)容。
在使用關聯(lián)數(shù)據(jù)時，可能會遭遇數(shù)據(jù)庫I/O問題?？紤]一下這個場景：有1000個Account，每一個關聯(lián)了1000個Order，而每個Order則包含25個OrderItem。如果嘗試將所有這些數(shù)據(jù)加載到內(nèi)存，執(zhí)行的SQL語句要超過1000000行（1條用來查詢Account，1000條用于Order，1000000條用于OrderItem），而創(chuàng)建的對象大約為2500萬——如果你真敢這么做，等你的系統(tǒng)管理員收拾你吧。
分析N＋1查詢問題
N＋1查詢問題是由于試圖加載多個父記錄（比如Account）的子記錄（Order）而引起的。因此，在查詢父記錄時，只需要1條語句，假設返回N條記錄，那么就需要再執(zhí)行N條語句來查詢子記錄，引發(fā)所謂的“N＋1查詢”。
這些問題的解決方案
延遲加載（Lazy load，在2.2中詳細講述）可以解決一部分內(nèi)存問題，它將加載過程打散為一些更小的過程。但是，它并沒有解決數(shù)據(jù)庫I/O問題，在最壞的情況下，它對數(shù)據(jù)庫的訪問次數(shù)與非延遲加載的版本是一樣的，因為加載數(shù)據(jù)時它的方法還是N＋1查詢（這個我們將在2.3中解決）。另一方面，當我們解決了N＋1查詢問題，減少了對數(shù)據(jù)庫的訪問，但我們的查詢結果卻包含著2500萬行記錄！
要決定是否使用復雜屬性，我們需要理解數(shù)據(jù)庫以及應用程序?qū)?shù)據(jù)庫的使用方式。如果您使用了本節(jié)中的技術，那可以省不少事兒，但如果誤用了它，也會有大麻煩。在接下來的兩節(jié)中，我們會分析如何根據(jù)目標選擇合適的策略。
讓我們從這個問題開始：像上面例子那樣將Account關聯(lián)到Order并將Order關聯(lián)到OrderItem是否合適？實際上，不是——order-to-orderitem關系是固定的，但是account-to-order關系則是不必要的。
我們是如是推理的：沒有所屬的Order，OrderItem是沒有意義的，而Account則是有意義的。一般情況下，沒有OrderItem，Order沒什么大用，相對的，不屬于任何Order的OrderItem是沒有意義的。另一方面，一個Account則可以認為是一個完整的對象。
但在我們的例子中，這種關系可以良好地描述相關的技術，因此我們會在一段時間內(nèi)一直使用它。
2.2 延遲加載（Lazy loading）
首先來看看延遲加載。如果不是對所有數(shù)據(jù)都馬上用到，那么延遲加載是有用的。例如，我們的程序首先在一個網(wǎng)頁顯示所有Account，然后銷售代理（我們的客戶）可以點擊一個Account來查看該Account的Order列表，然后可以再點擊一個Order來查看其所有的OrderItem信息。在這種情況下，每次都僅查詢一個列表。這是對延遲加載的合理使用。
譯注：在iBATIS的Java版本中，使用延遲加載前還需要進行配置SqlMapConfig.xml以打開該功能。在.NET版本中不需要配置等價的sqlMap.config。
使用了延遲加載后，我們就可以更合理地進行對象創(chuàng)建和對數(shù)據(jù)庫的訪問。（還是使用上面的例子）如果一個用戶關注到OrderItem層次的數(shù)據(jù)，我們需要進行三次查詢（一次是為Account，一次是Order，還有一次是OrderItem），應用程序則要創(chuàng)建2025個對象（1000個Account， 1000個Order，25個OrderItem）。效果明顯！而我們要做的僅僅是修改XML配置文件的一個特性（attribute）而已，無需改動代碼。
在一項不太嚴謹?shù)臏y試中，我們發(fā)現(xiàn)，對于同樣的對象關聯(lián)關系（如上面的Account- Order- ORderItem），在加載第一個列表數(shù)據(jù)時（Account列表），沒有使用延遲加載的版本花費的時間是使用了延遲加載的版本的三倍。但是，在加載所有數(shù)據(jù)時，延遲加載的版本的時間卻多了20％。很明顯，我們要根據(jù)數(shù)據(jù)加載的數(shù)量和時機來確定是否采用延遲加載。此時，經(jīng)驗是最重要的。
而有時您并不希望推遲數(shù)據(jù)的加載，而是希望在第一次請求的時候加載所有的數(shù)據(jù)。在這種情況下，您可以使用下節(jié)中的技術，它僅需要一次查詢即可。下節(jié)的方法避免了“N＋1查詢”。
2.3 避免“N＋1查詢”問題
我們來考慮如何避免“N＋1查詢”問題，這里可以使用連接語句（Join）。
這里用到的技術同前面類似。簡單的說，使用Result Map來定義對象間的關系，將頂層的Result Map關聯(lián)到映射語句。下面的例子的Data Map文件結構與前面大體一致，但是只需要執(zhí)行一條SQL語句。
這里面有三個Result Map，一是關于Account的，二是關于Order的，三是OrderItem的。
關于Account的Result Map有兩個作用：
映射Account對象本身的屬性。
告訴iBATIS如何映射下一層的關聯(lián)對象，這里是orderList。
Order的Result Map作用與之類似。
映射Order對象本身的屬性。
告訴iBATIS如何映射下一層的關聯(lián)對象，這里是orderItemList。
圖3orderItemList
我們的不太科學的測試表明，在加載少量數(shù)據(jù)時，該方法將原先方法的性能提高為7：1。我們猜想，對于例子中使用的2500萬條數(shù)據(jù)，兩種方法仍然不錯。
譯注：在iBATIS.NET DataMapper 1.1中，添加了groupBy特性，它將進一步改善性能。詳細內(nèi)容請參看相關文檔，本文使用的是DataMapper 1.5.1。
需要注意的是，盡管性能得到改善，內(nèi)存的消耗仍然與沒有使用延遲加載的版本相同。所有的記錄一起放入內(nèi)存，因此盡管它稍微快了一點，但內(nèi)存的消耗仍是問題。
譯注：在加載復雜屬性時可能出現(xiàn)兩方面的問題，一是對數(shù)據(jù)庫的訪問，二是創(chuàng)建對象時對內(nèi)存的消耗。我們可以采用延遲加載或Join的方法來解決這些問題，但是兩者都不是萬靈藥。延遲加載的原理時推遲對復雜屬性的加載，以減少對數(shù)據(jù)庫的訪問和對象的創(chuàng)建，但它的前提是復雜屬性不會馬上用到，否則的話，延遲就失去意義。Join的原理是通過一條SQL語句加載所有數(shù)據(jù)，這樣可以大幅度減少對數(shù)據(jù)庫的訪問量，它的前提是對象的數(shù)量不會太多。該如何選擇呢？下面的表格給出了簡單的原則：
圖4簡單的原則
譯注：另外，我覺得還有一條很重要的原則，那就是永遠只加載必需的數(shù)據(jù)。以上面的例子來說，我們不太可能會同時顯示1000個Account給用戶看，這時就不要同時加載1000個Account的數(shù)據(jù)了，可以通過分頁只顯示50條數(shù)據(jù)，在此基礎上再應用延遲加載或Join效果會很不錯。關于在Web項目中如何使用iBATIS進行分頁，請參看這篇文章。
關于iBATIS使用的相關以及復雜屬性映射相關的內(nèi)容就介紹到這里，希望對你有所幫助。
【編輯推薦】
