任何一個重要的數據庫無疑都會擁有不止一個依賴者。即使該數據庫只是簡單地被兩個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）私有數據庫

?

總結

以上是生活随笔為你收集整理的MyBatis知多少（14）分散的数据库系统的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。