数据访问层的优化思路(r10笔记第80天)

对于数据访问层的优化，我简单总结了一下，其实里面有很多的点子现在想起来有一种灵光一现的感觉，但是真真切切的，里面有不少是之前公司已经做到了的，所以一个做产品的公司真心很伟大，而能够沉淀下来如此多的东西，那绝对是一笔非常宝贵的财富，对于公司，对于个人都是持久的财富。

简单来说，如果处于初始阶段，基本就是这样的调用方式，数据访问层是直连DB层面的，尽管从后期的演进来说，可能会有一层cache，但是这个暂且不在数据访问层的优化范围内来谈。我们谈偏左一些的设计和改进。

这样的数据访问层，短期内是不会有问题的，而随着业务量增大，是肯定有问题的，问题实在太多我就讲几个重点的。

1. 可能因为系统的复杂程度，开发语言呢就有多重，不同的程序都需要访问同一个DB,在上面操作数据，如此想来真是细思恐极，这里面的数据隐患实在太多。
2. 不同的开发组都会有自己的数据处理流程和规范，所以大家都是各做各的，存在太多的冗余，而且如果因为开发同学的SQL功底，确切的是说不够细心认真，很可能会造成数据库层面的各种潜在问题。

对此有一些改进方法，一种就是现成的，不同的业务模块和系统肯定对于不同的应用层面，那么ERP的业务职能访问ERP的表，这个也无可厚非了，至少的设计层面来看，这个要清晰些了。

而数据库层面也必然是要做一些划分，这个可以放在不同的数据库用户下，或者不同的业务表名。 总之就是要有针对性。

其实做到这里，说实话，对问题没有任何的改变，各个开发团队还是自己的处理方式，如果需要添加数据表，那就初始化即可，自己提供SQL脚本，DBA部署。看起来是这样的，但是问题就是如此，里面存在太多的不确定，我们完全没法要求开发同学提供合适的约束名，索引名等，这些看起来似乎无关紧要的事情，其实深究起来还是蛮重要的。

怎么改进呢，那就是下图中的部分，我们在应用层面的对象和数据库层面的表进行了映射，这个工具就是做这件事情的，而这个工具的本质工作是什么呢，它会存放表的字段信息作为元数据，映射到数据库层面，就是SQL了。说简单一些，这个工具就是eclipse的一个插件，类似这样的工具，无论是哪个开发团队，都需要使用这个工具来进行应用和数据库层面的数据表映射。

而SQL怎么生成呢，通过这个图形工具，因为得到了对象的配置元数据，会基于这些信息来生成标准的SQL语句。这样就不用开发人员来牵扯更多初始化操作的部分了。

这样做其实还是很给力的，而且在一定程度上能够杜绝一大堆的潜在问题。

而接下来对于DBA来说就是一种梦魇了，那就是各个业务模块的变更多如牛毛。而且很多数据变更还存在一定的依赖性，或者说表在测试环境不需要初始化大量的分区，够用即可，但是到了线上环境，就很有必要了，而且测试环境的结构应该尽量简单，线上环境很可能是分布式的，数据库用户等配置就会格外复杂，对于这类的问题，很可能DBA就要从事更多的转换，而且很可能是手工转换工作。

对此一个很重要的改进就是使用PROFILE的改进，可以简单理解为模板的概念。测试环境有一套测试环境的模板，线上环境有线上的模板，这样一来初始化环境就会容易的多，而且不会那么劳神费力。

而这两个大问题解决之后能够解决绝大多数数据访问层的问题，那么还有类问题，那就是对于应用层面对象的属性变更，数据库层面就会难做到联动了。

我们可以用下面的图来说明。

不同的应用模块有不同的数据库访问细则实现，我们就叫做DAO吧。如果对表添加一个字段或者修改对象属性，这样一来在数据库访问层沃恩就需要做更多额改进和映射，都说表里的增删改查其实就那么回事，但是真摊到自己身上就是大事了，如果因为修改字段信息而需要动用修改核心的引用方式，就会给问题难上吉安娜。一格很单单的决定是，架构设计层面来完成这件事情，而难度最大的就是自动完成这些映射，而且DAO层面在这种情况下是不需要再次动用修改DAO层面的代码的，这个工作着实很难，而且很容易出现问题，但是确实做到了，而且用起来还真不错。一个良好的架构设计就会在很大程度上简化工作，使得开发同学不会纠结在更多的数据访问层的细节，而更加业务情况，结合了具体的场景，那么问题解决起来虽然是艰辛，但是回想起来还是希望能够帮助到一些需要的朋友。