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）私有数据库