漠漠睡今天接到一个小单，让从ZBlogPHP迁移数据到DEDECMS，虽然不知道为什么要迁移但是我知道，是因为我有一个插件是从DEDECMS迁移到ZBlogPHP所以才会找到我。迁出比迁进遇到的问题多，最显著的问题就是数据表的问题，dedecms文章数据由三个表管理，分别是“addonarticle|archives|arctiny”其实三个表也无所谓，但是你数据重复就是你的不对了，而且更坑爹的是：分类数据表的id都是smallint，最大数据不得超过65535，虽然绝大多数用户在使用的时候，不可能让
今天接到一个小单，让从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，那么多问题的一个程序，为啥还要往里面跑，
算了，谁给钱谁是大爷！打工去…………