数据库版本控制的实现与管理-优快云博客

实现数据库的版本控制的思路

资料引用:http://www.devdao.com/Article/532078.htm

数据库的版本控制与代码版本控制的区别在于数据库中的生产数据是现场创造的，当我们的表结构发生改变时，不能直接用drop table然后再create table，因为这样会导致生产数据丢失。而代码则完全由开发人员创造，可以用完全覆盖的方式升级。由于这点不同，致使数据库在版本控制的过程中必然要采用与代码不同的方法。

软件过程有一个过程方法叫迭代过程。对数据库的版本化，我们也可以采用这种类似的方法------后一个版本的脚本依赖于前一个版本的脚本，即当你要把数据库升级到第n个版本时，你必须先把数据库升级到第(n-1)个版本，以此递归。

我对对于数据库版本化的具体思路如下：
1.只存在一个基线版本；

2.在基线版本后的修改都是修正版本；

3.版本号遵从的格式通常是：主版本号.次版本号.修正号
修正版本SQL脚本的命名规则（表，视图，存储过程，用户，角色，规则，默认值，用户定义的数据类型，用户定义的函数，全文目录）；
a.涉及表、视图、存储过程、触发器的增加版本号为：V1.1.0.0。（主版本号不变，次版本号加一，修正号归零）
b.涉及表、视图、存储过程、触发器的更改、删除版本号为：V1.2.1.0。（主版本号和次版本号不变，修正号加一）
c.向表中增加、删除初始化数据的变化版本号为：V1.2.1.1。（在修正号后增加一个标识）

4.SQL脚本的格式：
每一个版本号为一个目录，目录下分别存放处理表、视图、存储过程等的SQL脚本；
/Database
├─V1.0.0.0
│      Full-Text.sql
│      PRocedures.sql
│      Tables.sql
│      Views.sql
│
├─V1.1.0.0
│      Tables.sql
│      Views.sql
│
├─V1.1.1.0
│      Full-Text.sql
│      Procedures.sql
│      Tables.sql
│      Views.sql
│
├─V1.1.1.1
│      Tables.sql
│
└─V1.1.2.0
        Full-Text.sql
        Procedures.sql
        Tables.sql
        Views.sql

5.关于数据库中的版本说明及更新记录：
在每个数据库中新建一个表，名称为DBVersion，用于记录数据库经历的版本记录以及最新的版本信息；

可用于SQL Server 2000的SQL代码
if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[DBVersion]') and OBJECTPROPERTY(id, N'IsUserTable') = 1)
drop table [dbo].[DBVersion]
GO
CREATE TABLE [dbo].[DBVersion] (
[DB_ID] [int] IDENTITY (1, 1) NOT NULL ,
[DB_Version] [varchar] (16) COLLATE Chinese_PRC_CI_AS NOT NULL ,
[DB_Update_Time] [datetime] NOT NULL ,
[DB_Remark] [varchar] (255) COLLATE Chinese_PRC_CI_AS NULL
) ON [PRIMARY]
GO

6.编写程序以实现以下功能：
读取Database目录的各个版本中的SQL文件，以实现升级或者新建数据。
对于升级数据库需要能够根据DBVersion表中的信息自动选择需要导入的SQL文件；或者提示用户当前可以升级到哪一些版本。
同时还需要有校验Database中版本的文件是否完整（包括版本完整和文件完整，这就需要存在一个校验文件）；

参考linux内核版本号的命名规则：

Linux内核版本号命名规则
Linux内核的版本号是有一定的规则的，版本号遵从的格式通常是：主版本号.次版本号.修正号。
主版本号和次版本号标志着重要的功能变动；修正号表示较小的功能变动。
以2.6.12版本为例，
2代表主版本号，6代表次版本号，12代表修正号。
其中次版本号还有特定的意义：如果次版本
号是偶数，则表示该内核是一个可放心使用的稳定版；如果次版本号是奇数，则表示该内核加
入了一些测试的新功能，是一个内部可能存在BUG的测试版
。如：2.5.74表示是一个测试版就的内核，2.6.12表示是一个稳定版的内核。
我们可以从Linux官方网站上：http://www.kernel.org/下载最新的内核代码！

数据库持续集成和版本控制

http://cdfive20.iteye.com/blog/607324

1 数据库开发的三个原则
1、 Never use a shared database server for development work
不要在共享的数据库上进行开发工作
2、 Always Have a Single, Authoritative Source For Your Schema

仅保留一份权威的Schema生成源
3、 Always Version Your Database

对你的数据库进行版本管理

2 为什么要版本化数据库
版本化数据库的目的就是为了能保证所做的改变能保持一致性、可控性、可测试性和可重现性。

我的指导思想：数据库版本管理类似于数据库备份，全备和增量备份相结合。全备就相当于完整脚本，增量备份就相当于增量脚本。

这样就避免数据库的更新从版本1跑到版本1000。

3 各个阶段的版本化
3.1 设计阶段
数据库采用PD进行设计，分为不同模块，用版本控制工具如cvs等管理pdm文件。

如下图：

3.2 开发阶段

增量脚本维护数据库；每次发新的版本重新生产数据库脚本，通过PD或者直接从数据库导出。

版本号遵从的格式通常是：主版本号.次版本号.修正号

比如1.0版本，修改数据库用脚本修改；如果发布新版本，则重新生产数据库脚本，为2.0版本

3.3 生产环境
生产环境中已经有生产数据，不能删除，通过增量维护。生产环境中可能遇到差异化控制，可以按照如下图结构进行维护

4 如何版本化

4.1 创建一个Schema基线
这个基线是一些数据库脚本（包括create table，alter table，drop table，insert data，update data，delete data等）。这些脚本可以位于同一.sql文件中，也可根据其它规划分别位于不同文件中，例如将视图脚本，初始化数据脚本，建表脚本分别置于不同的文件中。位于不同的文件中。应该写一个脚步，能一次执行所有命令

4.2 维护脚步
4.2.1 除视图、存储过程、函数
l 基本脚步不能修改

比如版本为2.0

l 新增数据库修改

版本变为2.1

除视图、存储过程、函数以外的数据库对象的修改

² 如果修改会影响存在数据

比如更改字段类型从varchar到int，维护增量脚本和data数据

² 如果修改不影响数据

直接通过增量脚本

每个版本里面的SQL执行也有专门脚本维护顺序。

4.2.2 管理视图、存储过程、函数
One File per Object，strategy is to script every view, stored procedure, and function into a separate file, then commit the files to source control。

就是将每个视图等作为一个单独的文件提交版本库来进行管理。

要有一个自动化工具或者脚本帮你完成如下步骤：

1、更新数据库的表

2、删掉所以视图和存储过程等

3、创建新的试图等

因为重建会尽快发现错误。

4.2.3 日志记录