数据库重构《Refactoring DataBase Evolutionary DataBase Design》介绍

说实话我也是前两周才知道有数据库重构这回事,当时听说这个概念的时候,唯一的反应就是:数据库居然也能重构?刚好上周去图书馆借书,看见了《数据库重构》这本书,就借回来看了几章。下面会结合自己的体会介绍一些这本书的一些观点。

数据库重构概念

数据库重构是对数据库Schema进行的简单改动,在保持行为和信息语义的前提下改进设计。

数据库重构可以重构数据库Schema的结构:比如表、视图的定义、修改; 重构数据库的功能:如存储过程、触发器等。

数据库重构的困难

数据库重构其实并不像代码重构那么简单,对数据库结构的改动,真的是牵一发而动全身。可能你要改动业务逻辑层、UI表示层、甚至是牵连到一些其它模 块、外部调用程序,还有像数据库里面的函数、存储过程、触发器等、光是把这些牵扯的例举出来,都会让你头皮发麻,还要大量的测试;而且对一个已经上线的系 统,你有这个魄力去重构吗?就算你有,未必其它同事、尤其拍板的人(经理)也未必同意,这里面的风险太大,代价太大了…..其实这都是因为数据库重构比代 码重构难,复杂。下面是我自己概括的一些:

  1. 代码重构只需要保持行为语义, 而数据库重构还要保持信息语义。
  2. 数据库架构所导致的耦合度(数据库与外部程序是高度耦合的),数据库重构变得相当复杂。按情况分分为单应用数据库、多应用数据库(相对复杂得 多),下面是我按书上图画的单应用数据库和多应用数据库。                                                                                                                                                                       数据库重构《Refactoring DataBase Evolutionary DataBase Design》介绍
  3. 数据库重构缺少工具支持。像代码重构,很多IDE(集成开发环境)都已经提供了代码重构功能,比如VS里面菜单栏里面有重构选项,许多人都经常使用。但是数据库到现在为止没啥工具支撑。相信数据库工具提供商以后也一定会增添这些功能的。
  4. 数据库设计、开发采用传统的、串行式的思维过程,基本上忽略了敏捷的方式(说实话,我对作者这个观点不太理解)。我的理解数据库开发一直采用传统的建模,设计,然后编码实现,没有采用反映现代方法学(如XP 和RUP)的演进式方式。
  5. 不是每个开发者对系统各部分、数据库架构都十分了解,不是每个人都精通数据库和应用程序开发。也就是说可能某人只精通数据库、而不精通C#开发, 那么重构就显得比较困难。还有很多人只了解系统的部分结构,而不了解整体,这对数据库重构影响很大,作者建议结对编程,DBA和架构师(技术人员)结对进 行数据库重构

数据库重构的分类

  1. 结构重构: 对一个或多个表或试图做一些变更。比如将一列从一个表移到另外一个表,将多用途的列拆分为一些单独的列。每个列用于单一用途。
  2. 数据质量重构:一种变更,改进了数据库中所包含信息的质量。例如,不允许列为空,确保它总是有值,或对一列采用统一格式,确保一致性。
  3. 参照完整性重构:一种变更,它确保参照的行在另外一个表的存在,并确保不需要的行被相应地删除。增加触发器支持两个实体间的层叠式删除。
  4. 架构重构。 一种变更,它从整体上改变了外部程序与数据库进行交互的方式。用存储过程取代部分代码和脚本。
  5. 方法重构: 对方法(存储过程、函数、触发器)的一种变更,改进方法质量,比如存储过程改名,把存储过程里面的*用相应的字段替换、、、、、
  6. 替换: 这不属于重构,转换时对数据Schema的一个变更,它改变了Schema的语义。

数据库味道

正如Flower在重构里面说的代码的坏味道一样,作者也尝试总结了一些数据库的坏味道。

  • 多用途的列。 如果一个列被用于多种用途,就有可能存在额外的代码来确保数据以“正确的方式”使用。个人认为像表里面用来判别性别、是否删除的字段这样的多用途列还不是坏味道,如果超出了两个应用,就应该考虑重构了。
  • 多用途的表。 如果一个表用来存放多种不同数据来源的数据。
  • 重复的数据。重复的数据对操作型数据库来说是一种严重的问题,因为数据存放在几个地方,不一致的机会就增加了。个人认为适当的冗余还是必须的。这个只能试情况而论。
  • 列太多的表。一个表包含太多的列时,说明表缺乏内聚——它试图存放来自几类实体的数据。我见过一个表几十个字段的设计,只能用“无语”来形容我的感受。
  • 行太多的表。大的表就有性能问题,查找就十分耗时,你这时就需要对表进行垂直分割:将一些列移到另外一个表,将一些行移到另外一个表,进行水平分割。
  • “智能”列:智能列是这样一种列,其中数据的不同位置代表了不同的概念。这个我不太了解(没有这方面的使用经验),作者的建议进行更小粒度的分割字段。
  • 害怕变化。如果你害怕改变你的数据库Schema,因为你担心更改会破坏其它很多应用程序,那么这就是一个明确的信号。

数据库重构在开发中的位置

作者提到了大多数面向数据技术本质上都是串行的。诸如逻辑数据建模或物理数据建模。希望数据库DBA采用类似开发者使用的现代演进式技术来开发,并 能从中获益。作者提供了一幅图关于在一些关键开发活动中的高层视图,这些活动发生在涉及对象和关系数据库的现代项目中。请注意,所有的箭头都是双向的。你 需要在这些活动之间来回迭代。同时注意没有定义起点和终点——显然这不是传统的串行式过程。

 数据库重构《Refactoring DataBase Evolutionary DataBase Design》介绍

上一篇:NVIDIA GPU 支持Containerd 小结


下一篇:基于OpenLDAP_MirrorMode的OpenLDAP高可用