【技术讨论】有兴趣的进，一起研究修改uid究竟涉及哪些东西?

不少人比较热衷于修改uid，虽然很早前就说过uid是关系到核心数据结构的，从来都不推荐修改，但还是很多人乐此不疲。

进入正题吧，很多作者之所以不随便放uid修改类的插件是因为涉及的东西太多了，稍有不慎就会毁掉全站数据。即便是所谓的uid商城，那也只是转移替换而已，算不上真正意义上的修改uid.

可以肯定，修改uid不涉及程序文件变动(config创始人的那个可能要跟着变动下)，那就把主要目标放到数据表上。这里不研究插件增加的表，只研究系统默认的保存uid的数据表。同样只研究保存单个uid的字段，对于那种保存 1,2,3,4 或者 {1},{2} 这种带有转码处理保存多个uid的字段一概不讨论。

关注的数据表有两大类，一类是有自增属性的，另一类是无自增属性的。

后面的好处理，直接修改即可，相信集合众人的力量是绝对能找得不漏的。但是前者很讨厌，随便修改会导致INSERT INTO开头的SQL语句出现键值重复(1062号错误)的错误。例如说你的网站本身UID已经分配到了50，然后你人为修改成100，那么等新会员注册到99后，再注册的新会员系统就会报错。

前者的那种数据表我稍后整理出来。后者那种，我认为可以这样处理。对所有INSERT INTO的操作语句（可以在db.class.php直接处理），如果发现重复键值的就跳过去，直到找到不重复的再插入数据。当然数据表的auto_increment的值也要相应的变动。不知道各路高手还有什么好想法没。

最后还是说一句，对于uid类插件，插件新手最好别随便去挖这个坑，等你对DZ数据库结构熟悉了也不迟；有两年以上开发插件经验并且对DZ数据库结构非常了解的老手，可以研究下。现在看来貌似也并不是不可能的任务，但是这个任务会非常艰巨，不过还是可以研究讨论下的。

哦 沙发啊？

uid还是不要修改的好,设计到的表太多.加上个别用户使用了插件等.你没有办法把每个插件的表都研究一遍的.

完全不想研究这个，不管是UID还是用户名，涉及的东西都太多，先不考虑对表的影响，单就表的关联来说，就太多的麻烦，而且很多插件也是用到UID或者用户名的，改了就等于所有涉及的数据都无效

其实我觉得不复杂，你先修改自动递增到某个范围（比如10000以内的未注册的号码归我了），之后注册的都是10000以上，然后要好的号码需要购买。

帐号转移的操作，实际上并不会难到哪里去的。

是啊，所以说敢改UID的作者是要有相当大的勇气的。

cwk32 发表于 2011-8-13 09:54
其实我觉得不复杂，你先修改自动递增到某个范围（比如10000以内的未注册的号码归我了），之后注册的都是100 ...

转移倒不难，现在研究的是真正意义上的修改UID

sw08，还是修改表的自动自增这个思想好，保证即使不用这款插件、插件失灵、升级影响也不大

cwk32 发表于 2011-8-13 10:00
sw08，还是修改表的自动自增这个思想好，保证即使不用这款插件、插件失灵、升级影响也不大

我现在设想，凡是涉及到INSERT INTO的语句，如果遇到了唯一属性的主键，然后就自动递归搜索跳过，直到找到可用的为止，不知道这样行不？

其实做好了，也能避免很多1062号错误的发生。

还有一个，似乎你的UID必须和UC保持联系