首先,是lz遇到的这问题,不是我遇到的.

我说的是,这种做法是业界(特指做网站的)习惯的一种处理方式.
把一个站的userId全加了@以后,一般要改掉用户中心.加上一重逻辑

比如你叫test1,密码123456,我也叫test1,密码abcdef,我是外来用户
那么登录的时候,先select ... where userId="test1" and password=md5("123456")
查不出的话,select ... where userId=concat("test1","@") and password=md5("abcdef")

"坑"不"坑"的不是你我能说了算的,历史遗留下来的东西,必须正视.
另外,你是业内混的么?

【 在 sayinger (言者) 的大作中提到: 】
: 既然如此你为何又要破坏这个规则呢，如果破坏这个规则也没什么要紧的，当初为何又有这个约束呢？如果有什么逻辑依赖于这个约束，这里就形成了一个我们称为“坑”的东西，为了防止自己掉进去，需要小心检查走过的路线...

活跃用户有10%就不错了.
10%里面有10%能响应网站发出的提议就不错了--除非用流氓手段.

【 在 marsteel (FoodMan) 的大作中提到: 】
: 让两个网站用户补充email，然后合并的网站以email地址作为登陆凭据
: 用户昵称就能容忍重名

开什么玩笑.
破坏用户已经养成的习惯等于自寻死路a.

【 在 sayinger (言者) 的大作中提到: 】
: 那就简单了，登录帐号与Id分离，登录帐号保留，重新分配Id，登录的时候让用户选定
自己所属集合即可。
--
修改:mpyu FROM 61.148.61.*
FROM 61.148.61.*