说起用户表，大概是每个应用/网站立项动工（码农们）考虑的第一件事情。用户表结构的设计，算是整个后台架构的基石。如果基石不稳，待到后面需求跟进了发现不能应付，回过头来反复修改用户表，要大大小小作改动的地方也不少。与其如此，不妨设计用户表之初就考虑可拓展性，争取不需要太多额外代价的情况下一步到位
示例一：
本例使用两个表 passport，profile 完成网站会员系统。
首先说说passport表，你也要以使用user或member等等命名，这个表设计尽可能地简单，不要使用过多字段。仅保存登录所必须用到的字段，如user,password,nickname,email... 登录帐号和密码做复合索引。
然后是profile表，这个表与passport是1:1关系，保存用户详细信息
这样设计可以保证海量用户登录时的速度。
示例二：
无论username+password，还是phone+password，都是一种用户信息+密码的验证形式；再来理解第三方登录，其实它也是用户信息+密码的形式，用户信息即第三方系统中的ID（第三方登录一定会给一个在他们系统中的唯一标识），密码即access_token，只不过是一种有使用时效定期修改的密码。所以我们把它抽象出了用户基础信息表加上用户授权信息表的形式。
用户基础信息表 users
id
nickname
avatar
用户授权信息表 user_auths
id
user_id
identity_type 登录类型（手机号 邮箱 用户名）或第三方应用名称（微信 微博等）
identifier 标识（手机号 邮箱 用户名或第三方应用的唯一标识）
credential 密码凭证（站内的保存密码，站外的不保存或保存token）
这个系统最大的特色就是，用户信息表不保存任何密码，不保存任何登录信息（如用户名、手机号、邮箱），只留有昵称、头像等基础信息。所有和授权相关（且基本前端展示无关的），都放在用户信息授权表，用户信息表和用户授权表是一对多的关系。说起来太抽象，show me the code.
users
| id | nickname | avatar |
|---|---|---|
| 1 | 慕容雪村 | http://…/avatar.jpg |
| 2 | 魔力鸟 | http://…/avatar2.jpg |
| 3 | 科比 | http://…/avatar3.jpg |
user_auths
| id | user_id | identity_type | identifier | credential |
|---|---|---|---|---|
| 1 | 1 | 123@example.com | password_hash(密码) | |
| 2 | 1 | phone | 13888888888 | password_hash(密码) |
| 3 | 1 | 微博UID | 微博access_token | |
| 4 | 2 | username | moliniao | password_hash(密码) |
| 5 | 3 | weixin | 微信UserName | 微信token |
如果使用第三方登录，则只要判断 SELECT * FROM user_auths WHERE type=’weixin’ and identifier=’微信UserName’ ，如果有记录，则直接登录成功，使用新的token更新原token。假设与微信服务器通信不被劫持的情况下无需判断凭证问题。
通过这个表结构设计，使许多原来纠结的问题瞬间解决，说说优点吧
一，站内登录类型无限拓展，代码改动小。如果真要支持身份证登录了，只要少许几处改动，无需修改表结构。
二，第三方登录类型可用工厂模式批量拓展，新增第三方登录类型的开发成本降到最低。
三，原来条件下，应用需要验证手机号是否已验证和邮箱是否已验证，需要相对应多一个字段如 phone_verified 和 email_verified，如今只要在user_auths表中增加一个统一的verified字段，每种登录方式都可以直观看到是否已验证情况。基于信任第三方登录的数据准确性，默认第三方登录都是已验证。如果用户修改登录手机号或登录邮箱，也能清晰跟踪每一步的完成度。
四，可按需绑定任意数量的同类型登录方式，即一个用户可以绑定多个微信，可以有多个邮箱，可以有多个手机号，是不是很赞？当然你也可以限制一种登录方式只有一条记录。
五，在user_auths添加相应的时间和IP地址，就可以更加完整地跟踪用户的使用习惯，比如，已经不使用微博登录两年多，已经绑定微信300天
六，即使完全使用第三方帐号登录，可在前端做到“无需注册本站帐号”的效果。过去许多网站虽然支持第三方帐号登录，但出于留存用户等原因，第一次微博登录回来，让你再填写一套他们网站的邮箱、密码等信息，也就失去了微博登录的最大意义。从技术上说，原有的结构导致除了在微博用户表建立一个条目外，必须在用户表建立一条对应的条目，而且一般情况下不能让用户表里的邮箱或者用户名和密码留空。用户体验好的，邮箱自动生成 微博ID@id.weibo.sina.com ，密码则随机生成。至于体验不好的，只能说早知道还不如不用微博登录呢！现在呢，我们的这个用户表结构则完全没有这样的困扰，只要微博提供的昵称和头像地址就可以生成这个用户，再关联他的微博登录记录。而且我们的表结构意味着，用户可以解除他的所有登录方式，于是这个账户便彻底变成了没法登录的僵尸（解决办法是在代码里加一个限制，至少保留一条user_auths的记录）。如果你非得得到用户的邮箱，那么每次登录的时候看到他不存在一条identify_type为email的记录，则弹窗弹死他，让他赶快填邮箱，否则啥都别干。
七，提升了逻辑思维能力。抽象出事物本质是码农必备职业素养，通过对用户表结构的学习研究，提高了鄙人的各方面技能，从此写代码一路顺风顺水…
八，如果你说邮箱和手机号就是用户信息的组成部分，他们依然需要体现在users表中作为前端展示？没问题，users表尽管拓展，users表里依然有email,phone，但他们仅仅作为“展示用途”，和昵称、头像、或者性别这些属性没有本质区别。在用户信息表与用户授权登录拆分后，用户信息表可以随时增加任意字段，加星座，加生日，都没问题，只需要在前端展示时多几个输入框，录入时多几行代码，与用户登录相关的问题做到最大程度解耦。
有利必有弊，说说缺点。
一，原先的用户判断由1次SQL变成2次SQL请求。
二，用户同时存在邮箱、用户名、手机号等多种站内登录方式时，改密码时必须一起改，否则就变成了邮箱+新密码，手机号+旧密码访问了，肯定是很诡异的情况。如果考虑到这一点，又要在user_auths表中新增一个表示站内登录方式或第三方登录方式的标识字段。
三，代码量增加了，有些情况下逻辑判断增加了，难度增大了。举个例子，无论用户是否已登录，无论用户是否已注册过，都是点击同一链接前往微博第三方授权后返回，可能出现几种情况：
1，该微博在本站未注册过，很好，直接给他注册关联并登录；
2，该微博已经在本站存在，当前用户未登录，直接登录成功；
3，该微博未在本站注册，但当前用户已经登录并关联的是另一个微博帐号，作何处理取决于是否允许绑定多个微博帐号；
4，该微博未在本站注册过，当前用户已登录，尝试进行绑定操作；
5，该微博已经注册，用户又已使用该帐号登录，为何他重复绑定自己- -.
6，该微博已经在本站存在，但当前用户已经登录并关联的是另一个微博帐号，作何处理？切换用户或是报错？（画一个流程图能更好描述这个问题）这个问题与采用的数据结构没有关系，只是在做第三方帐号注册登录时遇到的各种情况，在此一并整理。
参考：
1.http://wpceo.com/user-database-table-design/
2.http://www.netkiller.cn/architect/database/user.html
