加个'@'就能保证不重名了？

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

人那是SSO，跟楼主的需求不一样

【 在 ENV (白天图生存，晚上谋发展) 的大作中提到: 】
: 参考sohu跟chinaren合并的做法
--
FROM 202.106.68.*

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

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

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

【 在 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.*

真合并也是可以的，只是登录名实质上由原来的1个字段变成2个字段，分成两张表相当于做了个手动分区，放一张表里没什么问题。

至于说用户选择，其实完全可以不变。很简单，这两个站点的用户，本来就“习惯”在不同地方登录的，在这两个入口隐式声明一下自己就可以了，用户根本感觉不到有什么区别。
只有希望给用户一个新的登录界面的时候，比方说要搞SSO了，才会存在用户选择来显示声明自己来源的问题。而这种情况对用户来说，本来就是一个新东西，多一个选项已经是次要问题了。

【 在 fqqq (土土.土语村言) 的大作中提到: 】
: 做了个xmlprc的server ,持续链接两个数据库，登录的时候按照上面兄弟的做法
: 用户选择一下是哪个站点的，php链接xmlrpc的server认证
: 在新的应用中不冲突就可以了.
:   目前看问题解决了一部分。  等待上面决策一下，将来以哪边用户为主，另外一边的
: 导入， username重叠的提供选项，要么换，要么加别的后缀。
:   其实这个讨论挺有意义的，不是说多么深，但是很现实，
:   也没有什么绝对正确的答案,但是感觉国内网站开发还是挺乱的，  不过确实有规划
: 的
: 好多网站， 也有规划的不怎么样的网站。另外就是网站是个动态的，需要持续改进，
: 开始的架构很重要，不一定功能多强大，但是起步的扩展性，兼容性必须做好。
:   有些网站开始就没打算做大似的，表就三张，内容一多用户一多全得打补丁，拆
: 表导用户， 折腾个没完没了。
:   烦死.
:   谢谢大家都讨论， 以后多聊聊，不见得非要怎么地， 就是多个角度讨论问题比较
: 好。不过大家别斗气，我看还是年轻气盛的多.有空怎么可以搞个数据库，两千万用户2
: 亿内容的，架起来用loadrunner比一下，看谁的快，我觉得这种还是比较锻炼的
--
FROM 202.106.68.*