这样绝对不行.
必须改逻辑:)

【 在 fqqq (土土.土语村言) 的大作中提到: 】
:  我想到一个好处， 就是认证逻辑都不用改，告知另一个网站的用户登录的时候
: 自己在ID后加一个@.
--
FROM 61.148.61.*

我只想问一句：

我强制用户做啥了？

【 在 mpyu (猫扑老鱼) 的大作中提到: 】
: laf,我没想跟你抬杠,只是想说你没啥常识.
: 事实上随便拎出一个公司,无论多么牛逼,线上跑的代码基本都是一砣~
: 需求的变化,人员的变动,公司的并购,那是常有的事.
: 就算是上线初期,产品完美无瑕,跑过一阵,改过几轮,照样变的逻辑不可理喻.
: 老的系统,乱七八糟的需求,必须兼容,而无论内部怎么折腾,你绝对不能
: 强制用户去作些什么,我不指望你能认同我的说法,呵呵,会有人认同的.
--
FROM 202.106.68.*

在id后面加个下拉框?

[ id ] @ [ foo.com  v]
          |bar.com |
           --------'
[ pswd ]


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

死用户正好删除啊
【 在 fqqq (土土.土语村言) 的大作中提到: 】
:   您说的有道理， 这样其实也可以过滤一遍有效用户，我们系统死户也不少.
--
FROM 61.149.191.*

做了个xmlprc的server ,持续链接两个数据库，登录的时候按照上面兄弟的做法
用户选择一下是哪个站点的，php链接xmlrpc的server认证
在新的应用中不冲突就可以了.
  
  目前看问题解决了一部分。  等待上面决策一下，将来以哪边用户为主，另外一边的
导入， username重叠的提供选项，要么换，要么加别的后缀。
  其实这个讨论挺有意义的，不是说多么深，但是很现实，
  也没有什么绝对正确的答案,但是感觉国内网站开发还是挺乱的，  不过确实有规划
的
好多网站， 也有规划的不怎么样的网站。另外就是网站是个动态的，需要持续改进，
开始的架构很重要，不一定功能多强大，但是起步的扩展性，兼容性必须做好。
  
  有些网站开始就没打算做大似的，表就三张，内容一多用户一多全得打补丁，拆
表导用户， 折腾个没完没了。
  烦死.

  谢谢大家都讨论， 以后多聊聊，不见得非要怎么地， 就是多个角度讨论问题比较
好。不过大家别斗气，我看还是年轻气盛的多.有空怎么可以搞个数据库，两千万用户2
亿内容的，架起来用loadrunner比一下，看谁的快，我觉得这种还是比较锻炼的
--
修改:fqqq FROM 123.113.114.*
FROM 123.113.114.*