记录一次比较大型的ZBLOG数据库转换操作

接客户的要求，4个ZBLOG ASP站点，合并到同一个ZBLOGPHP，要求文章URL保持不变。

大概介绍一下四个站的数据情况。

1、主站mssql，三个子站使用的是access。

2、文章大概加起来6000多

3、评论大概不到100万

4、标签大概不到一千。

5、分类总计十几个的样子。

最开始想的总是简单

接单的时候想法也是比较简单的，只是没想到数据量比较大的时候，官方提供的转换工具都沦陷了：

1、a2p  Z-BlogPHP转换工具 这组插件在导出数据的时候，随机抽风，乱码。无法使用。

2、MovableType数据格式导出，基本上如果100篇导出一次是可以的。但是数据太多的时候……无法使用。

好像只有这两个插件？

提出问题

然而更困扰的是，没人操作过多个ASP转入同一个PHP站的事情，这有很多需要引入的问题。

1、文章ID重复，多个站点ID都是从1开始累加的，分类、评论、tag、用户也有这个问题。

2、简单无脑的修改文章ID，会导致评论错乱，A文章的评论可能会跑到B文章下面去，分类和Tag也有这个问题。

3、ZBLOG的文章url，在没有设置文章的别名Alias的时候，是和文章ID强关联的，如果修改了文章ID，那么Url也会跟着变化。

解决问题

鉴于以上这些问题，经过思考和验证，可以通过以下方式来进行合并解决。

1、对四个站的数据库中的文章、分类、评论、标签，主ID进行备份。因为access可能无法一次执行多条sql语句，所以只能一条一条复制过去执行...

//备份文章ID
alter TABLE  blog_Article add COLUMN  log_ID_backup char(255);
update blog_Article set log_ID_backup = log_ID;

alter TABLE  blog_Article add COLUMN  log_from char(255);
update blog_Article set log_from = 'lusongsong';


//备份分类ID
alter TABLE  blog_Category add COLUMN  cate_ID_backup char(255);
update blog_Category set cate_ID_backup = cate_ID;

alter TABLE  blog_Category add COLUMN  cate_from char(255);
update blog_Category set cate_from = 'lusongsong';


//备份评论ID
alter TABLE  blog_Comment add COLUMN  comm_ID_backup char(255);
update blog_Comment set comm_ID_backup = comm_ID;

alter TABLE  blog_Comment add COLUMN  log_ID_backup char(255);
update blog_Comment set log_ID_backup = log_ID;

alter TABLE  blog_Comment add COLUMN  comm_from char(255);
update blog_Comment set comm_from = 'lusongsong';



//备份Tags ID
alter TABLE  blog_Tag add COLUMN  tag_ID_backup char(255);
update blog_Tag set tag_ID_backup = tag_ID;

alter TABLE  blog_Tag add COLUMN  tag_from char(255);
update blog_Tag set tag_from = 'lusongsong';

2、因为文章分类和发布用户数量比较少，手动搞定。需要对增加后的分类做一下修改和替换。

//从站点分类作为新增分类加入
blog
update blog_Article set log_CateID = 8 where log_CateID=1;
update blog_Article set log_CateID = 9 where log_CateID=2;
update blog_Article set log_CateID = 10 where log_CateID=3;
info
update blog_Article set log_CateID = 11 where log_CateID=1;
yulu
update blog_Article set log_CateID = 12 where log_CateID=1;
update blog_Article set log_CateID = 13 where log_CateID=2;
update blog_Article set log_CateID = 14 where log_CateID=3;
update blog_Article set log_CateID = 15 where log_CateID=4;
//从站点文章用户归属处理
update blog_Article set log_AuthorID = 15 where log_AuthorID=2;
update blog_Article set log_AuthorID = 19 where log_AuthorID=3;
update blog_Article set log_AuthorID = 18 where log_AuthorID=4;
update blog_Article set log_AuthorID = 20 where log_AuthorID=5;
update blog_Article set log_AuthorID = 21 where log_AuthorID=6;
update blog_Article set log_AuthorID = 22 where log_AuthorID=7;

3、扩展三个子站数据库中的文章、评论、标签的主ID，防止导入的时候发生覆盖。

update blog_Article set log_ID = log_ID + 3333 //注意要先将主键属性、自动编号去掉。
update blog_Comment set comm_ID2 = comm_ID + 555555 //新建一个字段，评论太多了，本地测试无法修改字段属性了...
update blog_Tag set tag_ID = tag_ID + 222

4、使用navicat将主站先导入mysql。

5、使用插件将对应数据库迁移至zblogphp的表(插件就不说怎么写了哈，主要是写数据库的思路)。插件主要要注意的问题是，几十万评论的操作，要分页处理，不要一口气都转完。本地测试的时候一口气直接转，不是内存爆也不是CPU爆，而是phpcgi直接挂了…………

6、对于三个子站的数据，重复4、5两个步骤，数据转换完成。对于转换后的数据做一下检查，没发现异常就可以了。

7、对于文章Url的处理，包含两个部分：

7.1 首先需要拦截Url输出的接口(目前的ZBLOGPHP 1.4版本还没有，只好先自己写一个)，将输出的格式来源进行修改。

7.2 拦截系统的ViewAuto部分，当url无法匹配系统url规则的时候，把inpurl修改一下再丢给viewpost函数。

至此，数据转换完成，Url保持和原四个站点的Url相同。

总结

很少遇到有机会操作一次数据这么大的站，相对ZBLOG来说一般情况下遇到的都是小规模站点，尤其评论数量近百万的级别更是凤毛麟角。不过这也从侧面反应出一个问题，ZBLOG官方提供的工具包括官方应用中心其他的一些主题、插件，很少有对大数据专门做过优化的，一旦遇上这种数据量很大的问题，就都无法正常工作了。对于具体问题具体分析，掌握主要问题点，一一处理就行了。至于数据库的转换和Url的调整可能每个人都会有不同的方法，技术就是一层窗户纸嘛。