因为会有重名的userId,所以,加个标记,区分原来是哪个网站过来的用户.
这么搞是有点恶心,但是这好像是个常规且普遍的处理方式.
【 在 sayinger (言者) 的大作中提到: 】
: 为啥要加'@'
--
FROM 61.148.61.*

首先,是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.*

laf,我没想跟你抬杠,只是想说你没啥常识.

事实上随便拎出一个公司,无论多么牛逼,线上跑的代码基本都是一砣~
需求的变化,人员的变动,公司的并购,那是常有的事.
就算是上线初期,产品完美无瑕,跑过一阵,改过几轮,照样变的逻辑不可理喻.
老的系统,乱七八糟的需求,必须兼容,而无论内部怎么折腾,你绝对不能
强制用户去作些什么,我不指望你能认同我的说法,呵呵,会有人认同的.

【 在 sayinger (言者) 的大作中提到: 】
: 这样敷衍了事的“业界”我还真没见多少
: 你这个搞法有什么几乎可以说必然会出现的问题就不用我说了吧，当然，反正你也不在乎
: 至于什么“响应网站发出的提议”、“破坏用户已经养成的习惯”简直不知所云
: ...................
--
FROM 61.148.61.*

用户资料,那可是宝贵东西,至少是忽悠投资的利器

假设你有一个站点,注册用户1000w,活跃用户20w
那投资人差不多该会来找你了,假如你删剩了50w用户
活跃用户有40w,那么对不起,投资人看都不看你...

唯用户论就好比唯学历论一样,细分析一下挺扯淡的.
但是人家就认这个.

你应该知道吧,现在的站点,删除用户从来都是打标记,
几乎没有说我要真正删除的... 这还不够说明问题么.

死了,尸体给老子留在这,也比没有强!

【 在 JulyClyde (torred) 的大作中提到: 】
: 死用户正好删除啊
--
FROM 61.48.6.*

慢表也是要去查的,大哥.
【 在 JulyClyde (torred) 的大作中提到: 】
: 直接在死用户表里插数据，既不影响性能又不影响真实性
--
FROM 61.148.61.*