2019-1-11数据库重构

2、数据库味道
与“代码味道”概念相似，代码味道是代码中出现常见问题，表明需要进行重构。
数据库味道表明数据库需要重构。这些味道包括：

(1) 多用途的列
如一个列被用于多种用途，就可能存在额外的代码来确保源数据以“正确的方式”使用，这些代码常常会检查一个列或更多其它列的值。
比如：
某列用于存储某人的生日，如果此人是顾客的话。假如此人是公司雇员，此列则用于存储入厂日期。

 

(2) 多用途的表
如一个表被用于存放几种类型的实体，就可能存在设计缺陷。
例如：
某个表Customer同时存放了人和公司的信息。

(3) 重复的数据
重复的数据对操作型数据库来说是一个严重的问题，因为如数据存放在几个地方，不一致的机会就增加了。

(4) 列太多的表
当一个表包含太多的列，则说明这个表缺乏内聚。
比如：
Customer表包含了一些列，存放了3种不同的地址（发货地址、账单地址、公司地址）或几个电话号码（家庭电话、工作电话、手机号等），你可能需要将这种结构进行标准化处理，加入Address和PhoneNumber表。

(5) “智能”列
“智能”列是这样一种列，其中数据的不同位置代表不同的概念。
例如：
客户ID的前4位数字代表客户的开户行，则客户ID就是一个“智能”列。因为你会解析它以取得更细粒度的信息，如开户行ID。

3、数据库重构
数据库重构是一种数据库实现技术，与代码重构相似，对数据库Schema进行重构，使得在上面增加东西变得容易。

上图提供了一些关键开发活动的高层视图，这些活动发生在涉及对象和关系数据库技术的现代项目中。需要在这些活动之间来回迭代。

数据库重构是演进式数据库开发的一个重要组成部分。还需要采用演进/敏捷的方式进行数据建模。
耦合越厉害，就越难重构。代码重构、数据库重构均是如此。
最简单的场景：单应用数据库。因为数据库Schema只与它本身和一个应用相耦合。
而在多应用的数据库架构中，你的数据库Schema可能与应用源码、持久框架、ORM工具、其它数据库(提供复制、数据抽取/加载等)、数据文件Schema、测试代码，甚至数据库自身等耦合在一起。

减少涉及数据库的耦合的一种有效方式是封装对数据库的访问。让外部程序通过持久层来访问数据库，可以实现对数据库访问的封装。
持久层有多种实现方式：
(1) 通过数据访问对象DAO，它实现了所需的SQL代码；
(2) 通过框架；
(3) 通过存储过程；
(4) 通过Web服务。

永远也不可能把耦合降到0，但肯定可以把它降到能管理的程度。

 

数据库重组:数据库使用较长一段时间后，因为一些增，删，改等操作，使得数据的分布索引及相关数据会变得比较凌乱，从而影响数据库的查询效率。 数据库重组即是将数据库的相关信息(索引、单表、表空间)重新组织，即删除原有的表或索引,重建空的表或索引后,再把数据导入新表或索引中.这个过程无误即数据库重组成功.但也有导入数据失败的情况.所以数据库重组的风险也比较大。

重构:对软件内部数据结构的一种调整,目的是在不改变软件表现形式的前提下,提高其可理解性,降低其修改成本; 在用户来看,程序的行为和结果没有任何的变化.重构只是对程序内部结构进行调整,让代码更加容易理解,然后更容易维护
　重构的好处:1.能改进软件设计使软件更容易被理解;2.能帮你找到bug;3.提高软件的开发速度
什么时候进行重构:三次法则:事不过三,三则重构.意思是说,一件事情,第一次只管去做,第二次做类似的事情会产生反感,但无论如何还是做了,第三次再做类似的事情,你就应该重构.在添加新功能时进行重构.
什么时候不进行重构:现有的程序无法运行,此时应该是重写程序,而不是重构程序，免得过了最后的交付期限