zoukankan      html  css  js  c++  java
  • 数据库重构《Refactoring DataBase Evolutionary DataBase Design》介绍

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

    数据库重构概念

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

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

    数据库重构的困难

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

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

    数据库重构的分类

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

    数据库味道

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

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

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

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

     

    扫描上面二维码关注我
    如果你真心觉得文章写得不错,而且对你有所帮助,那就不妨帮忙“推荐"一下,您的“推荐”和”打赏“将是我最大的写作动力!
    本文版权归作者所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接.
  • 相关阅读:
    LeetCode 264. Ugly Number II
    LeetCode 231. Power of Two
    LeetCode 263. Ugly Number
    LeetCode 136. Single Number
    LeetCode 69. Sqrt(x)
    LeetCode 66. Plus One
    LeetCode 70. Climbing Stairs
    LeetCode 628. Maximum Product of Three Numbers
    Leetcode 13. Roman to Integer
    大二暑假周进度报告03
  • 原文地址:https://www.cnblogs.com/kerrycode/p/1984260.html
Copyright © 2011-2022 走看看