记录一个ZblogPHP数据迁移到DEDECMS过程中遇到的问题

今天接到一个小单,让从ZBlogPHP迁移数据到DEDECMS,虽然不知道为什么要迁移但是我知道,是...

今天接到一个小单,让从ZBlogPHP迁移数据到DEDECMS,虽然不知道为什么要迁移

但是我知道,是因为我有一个插件是从DEDECMS迁移到ZBlogPHP所以才会找到我。

迁出比迁进遇到的问题多,最显著的问题就是数据表的问题,

dedecms文章数据由三个表管理,分别是“addonarticle|archives|arctiny”

其实三个表也无所谓,但是你数据重复就是你的不对了,

而且更坑爹的是:分类数据表的id都是smallint,最大数据不得超过65535,虽然绝大多数用户在使用的时候,不可能让数据达到65535,但是奇葩的问题就是,这位用户,分类表直接从id58跳到了8W+,然后就直接被mysql没收了

然后,再看管理文章的数据库表里面分类的id也是smallint,结果就尴尬了。

没办法,只能用sql批量更新数据了。


然后这篇文章,就进入了正题,

update dede_arctiny inner join zbp_post on dede_arctiny.id=zbp_post.log_ID set dede_arctiny.typeid=90 WHERE zbp_post.log_CateID=86596;

更新数据表A中分类的值为指定值 当 表A中id的值与表B的log_ID的值相等,且表B中的分类id为指定值

这就意味着,我需要写好几十条sql去更新

更新完还要重新写入原始分类ID为8W+的分类到dede的分类数据表,还要解决初始ID=1及后续ID可以正常使用的情况!阿西吧!!!!


再然后检查到标签,又有一个坑:标签名的结构为char(12),是改大点占用你家茅坑了?你让那些特殊字符/词组往哪放

但是毕竟这是dedecms自己的问题,这个锅我就不背了。。哎

不管就不管吧,然后再tag绑定中,居然是一个新表,简直哔了狗了,我只能说,幸好这个用户的每个标签绑定的文章数量不多,不然以int(10),就够呛啊。。。毕竟文章id已经到了52W


唉,这就是一部辛酸史,实在不理解DEDECMS作为那么多BUG,那么多问题的一个程序,为啥还要往里面跑,

算了,谁给钱谁是大爷!打工去…………

评论