数据库重构探讨系列 (1) 基础 1、数据库重构分成6类: 2、数据库味道 与代码味道概念相似,代码味道是代码中出现常见问题,表明需要进行重构。 数据库味道表明数据库需要重构。这些味道包括: (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,但肯定可以把它降到能管理的程度。