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）分散的数据库系统