致寻求重排UID类功能的朋友

在插件区已经看到很多朋友在找UID重排性质的功能 虽然也有人发布过这类功能的方案和方法 不过为了对各位站长朋友负责 我再次重申一下 这个功能的不可能性 希望可以引起各位朋友的注意 理解为什么无论如何都没有一个完美的方案来解决一个重排问题 首先看一下我个人不完全统计的一个表格:

tablename	uid	username	mix
access	1
activities	1
activityapplies	1	1
adminnotes		1
adminsessions	1
announcements		1
attachpaymentlog	2
banned		1
buddys	1
creditslog	1	1
debateposts	1		2
debates		1	3
favorites	1
forumfields			1
forumrecommend	2	1
forums			1
invites	2
magiclog	2
magicmarket	1	1
memberfields	1		1
membermagics	1
members	1	1
memberspaces	1
moderators	1
modworks	1
myposts	1
mythreads	1
onlinetime	1
orders	1	1
paymentlog	2
pms	2	1
pmsearchindex	1
polloptions			1
posts	1	1
promotions	1	1
ratelog	1	1
rewardlog	2
rsscaches		1
searchindex	1
sessions	3
spacecaches	1
subscriptions	1
threads	1	2
threadsmod	1	1
tradecomments	2	2
tradelog	2	2
trades	1	2
validating	1	1
videos	1
words		1
total	52	26	9

表格中第一列为discuz!6.0正式版中部分数据表的名称(省略前缀) 第二列为uid关联的字段数 第三列为username关联的字段数 第四列为涉及username或uid的混合类字段数 最后一行为统计
稍微解释一下 之所以说不完全统计 并不是这些数据不可靠 而是我个人作为一个普通应用者 无法保证将discuz中全部关联字段都理解得一清二楚 但列出的数据 都是经过测试和代码分析得出的结论 是真实可靠的 第二、三列所表达的不仅仅是uid、username命名的字段 很多地方字段名不同但关联性是一样的 而最后的混合列 实际上是多uid字段、多username字段、以及uid和username的混合 在某些情况下 并不需要单独的把uid和username放在一个字段 如forums表中的最后回复等
大家可以看到 仅仅是直接关联uid的字段就有50多个 假设一个5000用户论坛 进行一次uid重排 数据库查询量也是很可观的 因为uid重排需要空白uid判断等一系列内部操作 所以这个查询量绝不仅仅是5000×52那么简单
查询量的大小还不是问题的关键 因为我们可以用技术手段把大规模的查询改为循环执行 类似后台的更新论坛统计那样 再加上超高配置的服务器 5000用户也许不会把资源耗尽 mix类字段也可以按照dz的规则解释成独立的模式进行处理 无非是多N倍的查询
那么外部呢？ 比如supesite 比如插件 这些外部程序会对dz的uid字段有多大的关联？ 无法估计 也无法统计 只要是和用户关联的插件就难免用到uid 没人可以对这些未知的事情做预先估计 这也是不可能有完备的uid重排功能的重要原因
也许有人会说 我没装ss没装任何插件 帮我做一个给原版用的插件总可以吧 不是绝对不可能 但是这个只能由掌握最全面discuz数据库结构和全部应用的官方来做 但是这类极度消耗资源的东西 会有人去做么？ 做了下一次升级还要再做一套？ dz的功能越来越多 数据库越来越庞大 而真正能掌握全部数据库结构和应用的人只会越来越少 为什么？ 去研究一下软件工程吧 dz这类大型程序不会是一个人写的 一个团队可能也仅仅开发一个模块
说实话 我曾经想过要做一个类似的功能 但是不可能全面 不全面的结果就是可能存在内在的数据冲突 这样受损失的是使用这个功能的站长
不过话说回来 uid又不是QQ号码之类的可以卖钱可以增值 无非是一个索引的数据 为什么大家非要为了它给自己的网站找那么大的麻烦呢？？在此希望各位苦苦寻找此类功能的站长 不要在执着于此 好好建设自己的网站吧 祝各位一帆风顺