MyBatis知多少（15）數據模型

瘦數據模型是一種最爲臭名昭著而且問題多多的對關係數據庫系統的濫用。不幸的是，有時又的確須要瘦數據模型。所謂瘦數據模型，就是簡單地將每張表都設計爲一種通用數據結構，用於存儲名值對的集合。這很是像Java中的屬性文件。有時這些表也可用於存儲元數據，例如指望的數據類型等。這是必要的， 由於數據庫只容許一列有一種類型定義。要更好地理解瘦數據模型，考慮下面這個典型的地址數據的示例，如表1-2所示。

表1-2典型模型中的地址數據 ADDRESSJD STREET CITY STATE ZIP COUNTRY 1 123 Some Street San Francisco California 12345 USA 2 456 Another Street New York New York 54321 USA

很顯然這個地址數據表能夠進一步規I範化。例如，能夠建立COUNTRY (國家)、STATE (州)、 CITY (城市）和ZIP (郵編）這樣的關聯表。但當前這樣一個設計對於大多數應用程序來講既簡 單又高效，已經足夠了。除非你的需求的確很是複雜，不然這個模型應該不會有任何問題。

 

仍是使用以上的數據，	若是將它們放入一個瘦數據模型對應的表中，	結果將如表1-3所示。
	表1-3瘦數據模型中的地址數據
ADDRESSJD	FIELD	VALUE
1	STREET	123 Some Street
1	CITY	San Francisco

 

(續）
ADDRESS ID	FIELD	VALUE
1	STATE	California
1	ZIP	12345
1	COUNTRY	USA
2	STREET	456 Another Street
2	STATE	New York
2	ZIP	54321
2	COUNTRY	USA

 

這樣的設計絕對是場噩夢。首先，沒有任何可能對它進一步規範化了，雖然當前的模型只能 算做第一範式。其次，沒有任何機會建立與COUNTRY表、CITY表、STATE表或ZIP表的關聯關係了，由於咱們不可能在同一列上定義多個外鍵。再次，若是但願執行一條涉及多個地址字段（例如，執行一個以街道和城市做爲查詢條件的查詢語句）的「樣例查詢」，這樣的數據實在讓人頭痛，它可能須要一大堆複雜的子查詢。再看看更新的狀況，這樣的設計就性能來講也特別糟糕， 僅僅是插入一個地址就須要在同一張表上執行5條插入語句。這種狀況下出現鎖競爭甚至死鎖的 可能性也大大增長了。此外，這個瘦數據模型中記錄的數量整整是咱們的規範化數據模型的5倍。 因爲記錄數量過大，又缺乏明確的數據定義，並且更新一條記錄時須要的更新語句過多，建立有 效的索引也是不可能的了。

不用再多說了，這個設計確實問題多多，咱們爲什麼要不惜一切代價避免這樣的設計，緣由已經再明白不過了。但話說回來，這個設計也不是毫無用處，它惟一的用武之地就在於那些須要動態字段的應用程序。有些應用程序的確有這樣的需求，它容許用戶對他們的記錄添加額外的數據。 若是用戶但願能定義新的字段，而後在應用程序運行時動態地把數據插入到這些字段中，那麼這樣的模型就能夠工做得很好。也就是說，全部的已知數據仍是應該正確地規範化，而這些額外的動態字段則能夠經過關聯關係與這些已知數據創建父子關係。這樣的設計一樣存在咱們之 前討論過的全部問題，但它們被最小化了，由於大部分數據（極可能是那些最重要的數據）都 己經被正確地規範化了。

即便在一個企業數據庫中遇到了瘦數據模型，MyBatis也能夠幫助你處理它。要將若干個類映射爲瘦數據模型是很是困難的，甚至是根本不可能的，由於你連數據模型中可能存在哪些字段都 沒法明確。此時你最好將這樣的類映射爲一個散列表（hashtable)，而幸運的是iBATIS支持這種 映射。使用MyBatis,你沒必要將每一張表都映射爲一個用戶定義的類。MyBatis容許你將關係數據映 射爲Java基本類型（primitive)、Map實例、XML還有用戶定義類（如JavaBean)。這種巨大的靈 活性使得iBATIS對於包括瘦數據模型在內的複雜數據模型很是有效。

MyBatis被設計爲一個混合型解決方案，它並不試圖解決全部的問題，相反它只但願能解決那些最重要的問題。MyBatis從各類數據庫訪問工具中汲取了大量的優秀思想。像存儲過程同樣，全部的MyBatis語句都有一個簽名，定義了語句的名字和輸入輸出（封裝)。與內聯SQL相似，MyBatis容許SQL語句按照其最天然的方式書寫，而且能夠直接使用語言中的變量做爲輸入輸出參數和結 果。像動態SQL—樣，MyBatis容許在運行時修改SQL。這樣的查詢語句能夠根據用戶的請求動態 構建。從對象/關係映射工具中，MyBatis借用了許多概念，包括高速緩存、延遲加載，還有更高 級的事務管理。

在一個應用程序的架構中，MyBatis適用於持久層。MyBatis也經過提供一些特性來支持其餘層， 這些特性使得對全部這些層的需求的實現都變得更加容易。例如，一個Web搜索引擎可能須要搜 索結果的分頁列表。MyBatis支持這種特性，由於它容許査詢時指定返回結果的偏移量和行數量。這就使得分頁操做能夠在一個較低的層次上執行，同時保持數據庫細節能夠遠離咱們 的應用程序。

MyBatis可用於任何大小和用途的數據庫。首先，MyBatis很是適合於那些較小的應用程序數據庫，由於它很是容易學習和快速上手。其次，MyBatis對大型企業應用程序也很是合適，由於它沒有對數據庫的設計、行爲或者那些可能對咱們的應用程序如何使用數據庫產生影響的依賴關係作 任何假設。再次，即便是對於那些在設計上存在着爭議或者深陷於高層政策混亂之中的數據庫， MyBatis也能夠工做得很好。綜上所述，MyBatis被設計得很是靈活以致於幾乎可適用於任何狀況了。 固然，使用MyBatis也能夠爲你節省大量的時間，由於你再不用寫那些重複的、樣本同樣的代碼了。

討論了 MyBatis的理念和起源。後面將仔細解釋什麼是MyBatis以及它是如何工做的。

系列文章：

MyBatis知多少（1）

MyBatis知多少（2）

MyBatis知多少（3）

MyBatis知多少（4）MyBatis的優點

MyBatis知多少（5）業務對象模型

MyBatis知多少（6）表現層與業務邏輯層

MyBatis知多少（7）持久層

MyBatis知多少（8）關係型數據庫

MyBatis知多少（9）不一樣類型的數據庫

MyBatis知多少（10）應用程序數據庫

MyBatis知多少（11）企業數據庫

MyBatis知多少（12）私有數據庫

MyBatis知多少（13）MyBatis如何解決數據庫的常見問題

MyBatis知多少（14）分散的數據庫系統