浅谈数据库用户表结构设计，第三方登录

说起用户表，大概是每个应用/网站立项动工（码农们）考虑的第一件事情。用户表结构的设计，算是整个后台架构的基石。如果基石不稳，待到后面需求跟进了发现不能应付，回过头来反复修改用户表，要大大小小作改动的地方也不少。与其如此，不妨设计用户表之初就考虑可拓展性，争取不需要太多额外代价的情况下一步到位。

先前设计

id
username
password
用户名加上密码，解决简单需求，留个id作为其他表的外键。当然，那时候密码还可能是明文存储，好点的知道md5。

后来呢，随着业务需求的拓展，要加个用户状态 status 判断用户是否被封禁，注册时间和注册IP地址、上次登录时间和IP地址备查（并衍生出登录记录表，用来判断是否异地登录等，在此不表），用户角色/权限 role （又衍生出用户角色权限关系，还是另文讨论），业务也需要个人的个人信息如真实姓名、地址等也一股脑往上添加，现在形成了一个很完整的用户关系表。

id
username
password
realname
address
…
status
role
register_time
register_ip
login_time
login_ip
现在问题来了，进入Web2.0时代，微博开放了第三方网站登录，用微博帐号就能登录我们的网站，老板说，这个我们得要。加个微博用户登录表吧，当然，得和我们自己的用户表关联，这个微博用户信息表如下：

id 自增ID
user_id 关联本站用户ID
uid 微博唯一ID
access_token
access_expire
这还不算完，QQ又开放用户登录了，一下子要接入好多家第三方登录了，只能就着“微博用户信息表”继续加类型加判断，如果是每个第三方登录都新建一个表，肯定会疯的。

时代变了，进入了移动互联网时代，怎么也得支持个手机号登录吧？所以现在每家标配都是：用户名/邮箱/手机号登