数据库重构探讨系列(1)

数据库重构探讨系列

(1) 基础

1、数据库重构分成6类：

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，但肯定可以把它降到能管理的程度。