任何一个重要的数据库无疑都会拥有不止一个依赖者。即使该数据库只是简单地被两个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）私有数据库