单点登陆我们也是要的，  但是要先合并两个大用户群，然后再更多的业务上
实现单点登陆，目前是两个用户群一个事独立业务，另一个自己实现了部分的
sso.
  这么说吧， 我反正是很想砸烂这些从头开发，但是这显然是老总不能接受的.

【 在 sayinger (言者) 的大作中提到: 】
: 人那是SSO，跟楼主的需求不一样
--
FROM 119.255.34.*

  您说的有道理， 这样其实也可以过滤一遍有效用户，我们系统死户也不少.

【 在 marsteel (FoodMan) 的大作中提到: 】
: 没事啊，设定一个期限，比如2月14日之前完成email补充的用户赠送多少积分……
--
FROM 119.255.34.*

一个用户俩密码，匹配上哪个密码就用哪个老站点的用户登录
【 在 fqqq (土土.土语村言) 的大作中提到: 】
:  大网站，两个大的网站的用户ID要合并到一张表，怎么办。
:   那边提方案在一个网站的用户ID最后加一个'@'标志，
:   目前没想出会有什么问题， 请问有经验的，这个通常怎们做.
: ...................
--
FROM 210.83.48.*

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

这样敷衍了事的“业界”我还真没见多少

你这个搞法有什么几乎可以说必然会出现的问题就不用我说了吧，当然，反正你也不在乎

至于什么“响应网站发出的提议”、“破坏用户已经养成的习惯”简直不知所云

【 在 mpyu (猫扑老鱼) 的大作中提到: 】
: 首先,是lz遇到的这问题,不是我遇到的.
: 我说的是,这种做法是业界(特指做网站的)习惯的一种处理方式.
: 把一个站的userId全加了@以后,一般要改掉用户中心.加上一重逻辑
: 比如你叫test1,密码123456,我也叫test1,密码abcdef,我是外来用户
: 那么登录的时候,先select ... where userId="test1" and password=md5("123456")
: 查不出的话,select ... where userId=concat("test1","@") and password=md5("abcdef")
: "坑"不"坑"的不是你我能说了算的,历史遗留下来的东西,必须正事.
: 另外,你是业内混的么?
: 活跃用户有10%就不错了.
: 10%里面有10%能响应网站发出的提议就不错了--除非用流氓手段.
: 开什么玩笑.
: 破坏用户已经养成的习惯等于自寻死路a.
: 自己所属集合即可。
--
FROM 202.106.68.*