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

简介: 版权声明:本文为博主chszs的原创文章,未经博主允许不得转载。 https://blog.csdn.net/chszs/article/details/5347257 数据库重构探讨系列(2) 接上一篇文章,《数据库重构探讨系列(1)》(见http://blog.csdn.net/chszs/archive/2010/02/27/5332408.aspx)。
版权声明:本文为博主chszs的原创文章,未经博主允许不得转载。 https://blog.csdn.net/chszs/article/details/5347257

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

 

接上一篇文章,《数据库重构探讨系列(1)》(见http://blog.csdn.net/chszs/archive/2010/02/27/5332408.aspx )。


4、数据库重构实例
“余额Balance”列实际上描述的是“账户Account”实体,而不是“顾客Customer”实体。
因此如图所示,需要把“余额Balance”列从“顾客Customer”表移出,加入到“账户Account”表中。

图


重构的迭代活动如下:


(1) 验证数据库重构是否合适;
这个重构有意义吗?变更真的需要现在进行吗?值得这样去做吗?


(2) 选择最合适的数据库重构技术;
真正需要重构的是“使用正式数据源”


(3) 让原来的数据库Schema过时;
需要一个转换期,即“过时期”


(4) 前测试、中测试和后测试;
要能够轻易验证数据库在变更之后仍能与应用一起工作,就有信心对数据库Schema进行变更,做到这一点的唯一途径就是采用测试驱动开发TDD的方式。
TDD方式中,编写一个测试,编写足够代码,通常是使用数据定义语言DDL,来完成该测试。继续以这种方式工作,直到数据库重构完全实现。


(4.1) 测试数据库Schema;
数据库重构会影响数据库Schema,故需编写面向数据库的测试。可以从许多方面来检查数据库Schema:
· 存储过程和触发器
· 参照完整性RI
· 视图定义
· 缺省值
· 数据不变式
数据库测试工具:管理测试数据的工具DBUnit;测试存储过程的工具SQLUnit;还有针对数据测试的商业工具。


(4.2) 测试应用程序使用数据库Schema的方式;


(4.3) 检验数据迁移的有效性;
许多数据库重构技术要求迁移源数据,比如将数据值Customer.Balance复制到Account.Balance,需要检验每位顾客的正确余额确实进行了拷贝。


(4.4) 测试外部程序代码。

· 修改数据库Schema;


以上面的例子,需要加入Account.Balance列和两个触发器:SynchronizeAccountBalance和SynchronizeCustomerBalance。
完成此事的DDL代码:
ALTER TABLE Account ADD Balance Numeric;
COMMENT ON Account.Balance 'Move of Customer.Balance column, finaldate=2006-06-14';
CREATE OR REPLACE TRIGGER SynchronizeCustomerBalance
  BEFORE INSERT OR UPDATE
  ON Account
  REFERENCE OLD AS OLD NEW AS NEW
  FOR EACH ROW
  DECLARE
  BEGIN
    IF :NEW.Balance IS NOT NULL THEN
      UpdateCustomerBalance;
    END IF
  END;
/
COMMENT ON SynchronizeCustomerBalance 'Move of Customer.Balance column to Account,
dropdate = 2006-06-14';
CREATE OR REPLACE TRIGGER SynchronizeAccountBalance
  BEFORE INSERT OR UPDATE OR DELETE
  ON Customer
  REFERENCE OLD AS OLD NEW AS NEW
  FOR EACH ROW
  DECLARE
  BEGIN
    IF DELETING THEN
      DeleteCustomerIfAccountNotFound;
    END IF
    IF (UPDATING OR INSERTING) THEN
      IF :NEW.Balance IS NOT NULL THEN
        UpdateAccountBalanceForCustomer;
      END IF;
    END IF;
  END;
/
COMMENT ON SynchronizeAccountBalance 'Move of Customer.Balance column to Account, dropdate=2006-06-14'

对每次重构采用一些小脚本,原因是:简单性、正确性、版本控制。

实现重构的一个重要方面是,确保数据库Schema变更的部署遵守了公司的数据库开发指南。

· 迁移源数据;
当发现需要编写支持文档来描述一个表、一个列或一个存储过程时,说明需要对这部分Schema进行重构,使其更易于理解。
也许一次简单的改名就可以避免几段说明文档。设计越清晰,就越少需要文档。

· 修改外部访问程序;
数据库Schema变更时,常常需要重构原有的外部程序。

· 运行回归测试;
实现重构的一部分工作是对它进行测试,确保它能工作。

· 对工作进行版本控制;
把重构置于配置管理CM的控制之下。

· 宣布此次重构。
需要向感兴趣的各方沟通已经完成的数据库重构。
宣布工作的一个重要方面是更新相关的文档。还需要更新数据库的物理数据模型PDM。
注意:不用发布不成熟的数据模型。

数据库重构过程:
重构流程图

小结:数据库重构的工作室在开发沙盒中完成的,最好是由一个开发者和一个DBA结对完成。

目录
相关文章
|
2月前
|
运维 NoSQL BI
简道云搭载阿里云MongoDB数据库,帮助数以万计企业重构业务系统
通过与MongoDB和阿里云团队的合作,让简道云少走了弯路,保障了线上服务的长期稳定运行,提高了吞吐效率,并相应降低了线上运行成本
|
弹性计算 监控 NoSQL
数据库重构之路,以 OrientDB 到 NebulaGraph 为例
在业务逻辑复杂、技术栈不甚了解的情况下,如何在有限的时间完成对数据库的重构迁移工作?技术方案该如何拟定,灰度计划怎么拟定,项目排期如何规划…本文给你一个通用的解决思路,让你更好地完成数据库重构工作。
316 2
数据库重构之路,以 OrientDB 到 NebulaGraph 为例
|
敏捷开发 SQL 存储
「敏捷数据」数据库重构:适应业务快速变化
「敏捷数据」数据库重构:适应业务快速变化
「敏捷数据」数据库重构:适应业务快速变化
|
弹性计算 监控 NoSQL
数据库重构之路,以 OrientDB 到 NebulaGraph 为例
如果你想尝鲜图数据库 NebulaGraph,记得去 GitHub 下载、使用、(^з^)-☆ star 它 -> GitHub;和其他的 NebulaGraph 用户一起交流图数据库技术和应用技能,留下「你的名片」一起玩耍呀~
117 0
|
弹性计算 监控 NoSQL
图数据库系统重构之路:从OrientDB迁移到NebulaGraph 真实案例分享
图数据库系统重构之路:从OrientDB迁移到NebulaGraph 真实案例分享
197 0
|
存储 SQL 缓存
【机房重构】之数据库的操作
【机房重构】之数据库的操作
137 0
|
敏捷开发 SQL 存储
「首席架构师看敏捷数据」数据库重构:适应业务快速变化
「首席架构师看敏捷数据」数据库重构:适应业务快速变化
|
7月前
|
容灾 关系型数据库 分布式数据库
DB2下移分布式数据库OceanBase单元化重构最佳实践
DB2下移分布式数据库OceanBase单元化重构最佳实践。
468 0
DB2下移分布式数据库OceanBase单元化重构最佳实践
|
MySQL 关系型数据库 数据库