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

任何一個重要的數據庫無疑都會擁有不止一個依賴者。即便該數據庫只是簡單地被兩個Web 應用程序所共享，也有許多事情須要考慮。假設有一個名爲網上購物車的Web應用程序，它使用了一個包含類別代碼的數據庫。就網上購物車來講，類別代碼是靜態的，永遠不會變化，因此該應用程序高速緩存了這些代碼以提升性能。如今再假設有一個名爲網上管理器的Web應用程序，它是用於更新類別代碼的。這個網上管理器 應用程序運行在一個不一樣的服務器上，是一個徹底獨立的程序。那麼，設想一下，當網上管理器更新了一個類別代碼時，網上購物車如何知道該刷新本身高速緩存的類別代碼了呢。這是一個簡單的例子，但有時的確是一個複雜的問題。

不一樣的系統可能會以不一樣的方式訪問和使用數據庫。一個應用程序多是基於網絡的電子商務系統，它會執行不少數據庫更新和數據建立的操做。另外一個應用程序則多是一個規劃好的批處理任務，定時從一個要求獨佔訪問數據庫表的第三方接口中加載數據。可能還有一個應用程序是報表引擎，它持續地要求數據庫進行復雜的查詢操做。能夠很容易想象這樣的狀況會是多麼的複雜。

最重要的是，一旦訪問某個數據庫的系統超過一個，狀況就會變得有些複雜了。MyBatis在不少方面都能有所幫助。首先，MyBatis做爲持久化框架對全部類型的系統（包括事務系統、批處理 系統還有報表系統）都是有用的。這就是說，不管訪問給定數據庫的是什麼系統，MyBatis都是一個很是好用的工具。其次，若是可以使用MyBatis，或者甚至是像Java這樣的一致的平臺，那麼就 可使用分佈或高速緩存來在各個不一樣的系統之間進行通訊。最後，對於最複雜的狀況，你也可 以很容易地禁用iBATIS高速緩存，而後本身編寫能與當前狀況完美契合的特定查詢語句和更新語句，即便使用相同數據庫的其餘系統沒有禁用高速緩存。

複雜的鍵和關係

設計關係數據庫的本意就是須要它遵照一系列嚴格的設計規則。出於各類緣由，有時這些規則會被打破。若是某條規則被破壞、誤解或者過分使用，就有可能致使出現復 雜的鍵和關係。關係數據庫設計的規則要求，表中的每一條記錄都應當經過一個主鍵來惟一地標 識。最簡單的數據庫設計可能會使用一個毫無心義的鍵做爲主鍵。但也有一些數據庫設計可能會 使用一種所謂的天然鍵,此時真實數據的一部分被用做了鍵。即便如此，更加複雜 的設計還可能會使用由兩列或更多列組成的複合鍵。主鍵常常被用於在表與表之間建立關係。所 以任何複雜或錯誤的主鍵定義都會由於它與其餘表之間存在的關係而被傳播出去。

有時，主鍵規則也可能沒有被遵照。也就是說，有時數據根本就不存在主鍵。這就會使得數據庫查詢變得異常複雜，由於咱們沒法惟一地標識數據。這也會使得在表之間建立關係變得很是 困難和混亂。這還會對數據庫性能形成很差的影響，由於咱們每每會在主鍵上創建索引以提升性 能，且主鍵還被用來決定數據的物理順序。

在另一些狀況中，主鍵規則又可能被過分使用了。數據庫可能毫無實際理由地使用了複合天然鍵。這樣的設計就是過於認真地遵循規則和儘量地用最嚴格的方式實現規則帶來的結果。 使用天然鍵在表之間建立關係實際上會形成對一些真實數據的複製，這對於數據庫的維護來講往 往是一件糟糕的事情。複合鍵用於關係時就會形成更多的冗餘，由於這會用到關聯表中的好幾列， 只爲了惟一地標識一條記錄。在這兩種狀況下，因爲天然鍵和複合鍵的使用，數據庫的靈活性就 喪失了，由於天然鍵和複合鍵會給數據庫維護形成極大的困難，當須要進行數據遷移時更像是一 場「噩夢」。

MyBatis能夠處理任何類型的複雜鍵定義和關係。雖然最好仍是將數據庫設計得更合理一些， 但MyBatis的確能夠處理那些使用無心義鍵、天然鍵、複合鍵甚至根本沒有鍵的表。

數據模型的去規範化或過分規範化

關係數據庫的設計包括一個消除冗餘的過程。冗餘的消除很是重要，由於它保證了數據庫能 夠提供較好的性能且靈活而可維護。數據模型中消除冗餘的過程稱爲規範化（normalization)，規 範化的程度有好幾個級別。沒有通過任何處理的數據每每存在大量的數據冗餘，所以也被認爲是 未規範化的。規範化是一個複雜的話題，咱們在此不會討論過多細節。

當一個數據庫剛剛被設計出來時，咱們經常使用那些未經加工的數據來分析冗餘。數據庫管理員、 數據建模人員甚至是開發人員都會分析這些數據，而後使用一些用於消除冗餘的特定規則的集合 來對它們進行規範化。沒有通過規範化的數據模型會存在一些數據冗餘（即在不一樣的表中有相同 的數據），且每張表都有大量的記錄和大量的列。通過規範化的數據模型的冗餘就不多甚至沒有 了，這時模型中會存在較多的表，但每張表中只有幾列和幾條記錄。

沒有哪一個級別的規範化是完美的。一個未經規範化的模型具備簡單的優勢，甚至有時在性能 上也會具備一些優點。這種模型的數據存取速度可能比通過規範化的模型還更快。形成這種現象 的緣由是未經規範化的模型中須要執行的語句和關係演算更少，所以負擔也就更少。也就是說， 去規範化應該老是例外而不能做爲一條規則。良好的數據庫設計每每開始於一個「教條化」的規 範化模型，而後再根據須要對其去規範化。通過規範化後再去規範化的過程總比沒有規範化而需 要從新規範化來得簡單得多。所以，老是從一個規範化的數據模型開始數據庫設計吧。

也存在數據庫被過分規範化的狀況，其結果也會帶來不少問題。太多的表就須要建立太多的關係，以至難以維護。過分規範化的數據庫會形成的問題包括：當查詢數據庫時，須要執行不少錶鏈接操做；當更新關係緊密的數據時，須要執行不少更新語句。全部這些都會對數據庫性能形成負面影響。還有一點，當須要把這樣的數據模型映射到對象模型時，一般也會更加困難，由於你可能不但願你的對象模型擁有與數據模型同樣的如此細粒度的類。

去規範化的模型也可能存在問題，甚至可能比過分規範化的模型還要多。去規範化的模型容 易具備較多的記錄和較多的列。過多的記錄會對性能形成負面影響，緣由是查找時須要掃描的數據更多了。過多的列也存在一樣的問題，由於每條記錄的內容都更多了，所以每次執行更新或查詢時就須要更多的資源。對這樣的大表執行某些操做（如更新或查詢）時要格外當心，要保證只針對那些必要的列，切忌將那些無關列也攪和進來。還要說明的一點就是，對於去規範化的模型， 要建立有效的索引一般會很困難。

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）私有數據庫