数据库的版本控制与代码版本控制的区别在于数据库中的生产数据是现场创造的,当我们的表结构发生改变时,不能直接用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/下载最新的内核代码!
转载请以链接形式注名来源:SEO杂碎