数据库表设计：基于业务场景的用户表的设计

本站系统的用户登录设计

通常作为本站系统的登录，有三种设计方式：

• 用户名+密码
• 邮箱+密码
• 手机号+密码

那么该如何设计登录方式呢？

1.三种登录方式，功能是否重复？是否可以只实现其中一种？

功能并不重复。看情况实现。
理由如下：

• 网站还是需要用户名，用于区别内部用户。
• 当提及某个用户时，邮箱和手机号，用户可能不想公开。而提及昵称时，昵称可以重复，不能作区分。
• 用户名一旦选定不允许更改，邮箱和手机号作为第三方的系统，应该允许更改。
  

2.什么时候可以只用邮箱或手机进行登录？

邮箱或手机号是唯一的，但也同时具有“个人联系方式”的特点，与系统生成的UID具有不同的含义，个人应该具有控制自己的信息是否暴露在公共空间的自由。

当与其他用户的交互需求不高，即没有社交需求时，邮箱或手机号可以当做“户头”使用，比如银行、医院、工作站。

而像论坛、游戏等社交需求高的系统，作为“人”，应该保留用户名登录。

除非规定昵称必须唯一，此时可通过昵称“@”提及他人，那么也可以不实现用户名登录。

3.是否允许邮箱或手机号进行更改？

邮箱或手机号是可以更换的，虽然每个邮箱标记着一个单独的联系方式，并且互不重复，但是邮箱作为个人可变信息，应当允许消亡或者发生变动，甚至可以冒名顶替。

因为邮箱这个资产的控制者不属于当前信息系统，是一个第三方的（当然也可以是本系统提供的邮箱服务，但是从当前用户系统来看，属于第三方）。

用户名的控制权却完全属于当前信息系统。

**一个运行良好的信息系统，显然不应该为第三方系统的长久存在作任何担保。**但是它可以确定用户名，以及用户名内部对应的 UID 确是完全自己控制，并且决定处理策略的。

例如：QQ号作为该系统的用户名UID，是随机生成的，没有与其他第三方系统挂钩。然而，部分腾讯的游戏只支持QQ号或QQ邮箱登录，这时因为他们属于同一公司，可以保证系统可靠。可以不设置用户名+密码的方式登录。
而像yahoo邮箱面临关闭这样的事件，若自己的系统只设置邮箱登录，通过此邮箱找回密码就面临失效。

第三方登录的设计

设计案例1

参考：浅谈数据库用户表结构设计，第三方登录的设计如下：

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|email|123@example.com|password_hash(密码)|
|2|1|phone|13888888888|password_hash(密码)|
|3|1|weibo|微博UID|微博access_token|
|4|2|username|moliniao|password_hash(密码)|
|5|3|weixin|微信UserName|微信token|

该思路是将用户授权和用户信息分开。用户信息好理解，需要的信息都放这种表中就行了。
而用户授权表中，id主键自增，user_id可重复，identifier为唯一键。
登录验证过程如下：
1.通过正则验证或入口第三方登录验证，判断登录类型，比如，手机号。
2.通过sql查询语句SELECT * FROM user_auths WHERE type=’phone’ and identifier=’手机号’取出该条目，并进行验证密码
3.验证通过后取出user_id的用户信息

该设计的优点：

• 站内登录类型无限扩展，无需更改表结构
• 手机验证和邮箱验证由原来的两个验证字段phone_verified 和 email_verified，变为一个verified字段即可。而第三方登录验证都默认已认证。
• 可绑定任意数量的同类型验证方式，比如多个手机号登录，多个微信或邮箱登录同个账号。或者规定只能登录一条。
• 可在前端做到“无需注册本站帐号”的效果，不用再注册一遍本站账号。
• 手机或邮箱作为联系方式，仍然可以在用户信息表中作为字段显示。

该设计的缺点：

• 由1次SQL变成2次SQL
• 当改密码时，邮箱、用户名、手机号等等的密码要一起改，否则就变成了邮箱+新密码，手机号+旧密码访问了，解决方式是增加字段，区分本站账号和第三方登录账号。
• 代码量增加了，逻辑判断更复杂了。

根据上述分析，最终设计表结构如下：

|id|nickname|avatar|sex|birthday
|1|慕容雪村|http://…/avatar.jpg|男|19980101

user_auths
|id|user_id|identity_type|identifier|credential|verified|is_self
|1|1|email|123@example.com|password_hash(密码)|1|1
|2|1|phone|13888888888|password_hash(密码)|1|1
|3|1|weibo|微博UID|微博access_token|1|1

设计案例2

根据上述设计案例，我认为这种数据库表结构设计并不让人十分满意。
他将用户授权和用户信息表分开的思路，我十分认可。然而，用户授权表太复杂了，逻辑和代码量增大了，意义含糊不清。
由于用户登录时，要考虑验证码，用户输入密码错误次数，用户是否被禁用，这些都与本站系统有关。
因此考虑一个用例对应一个数据表，从本站输入账号密码和从第三方登录获得授权属于不同的用例，本站登录与第三方登录的数据表应该分开。

为什么使用第三方登录？

我们主要考虑，用户注册或登录时，不愿意设置密码，不愿意填各种资料。而用户在此之前却已经有QQ账号、微信账号等唯一openid。

基于对这些系统的信任，可以通过唯一openid作为登录本站系统的凭证，并获得附带的信息（昵称、头像等）。

所以第三方登录有以下意图：

• 绑定后的账户，在忘记本站账号密码的情况下，进行另一种登录的手段。
• 首次注册的用户，在不需要提供账号密码的情况下，进行快速注册和登录，做好引流。

第三方登录有哪些不足之处：

由于本站系统要求的信息五花八门，而第三方系统不一定会提供，比如手机，电子邮箱，这些信息为了以后做营销和找回密码等使用。

有时本站账号是强烈需要的，为了摆脱外部系统的依赖，或为了获取更多用户信息，需要第三方系统与本站账号进行绑定。

但是，首次第三方注册后，很多网站需要又立即注册本站账号，用户本来以为可以快速注册登录，实际上花费时间更长了，可能感觉受到欺骗，放弃注册。

解决方法：

• 不提供第三方登录
• 允许第三方登录，首次注册后，以后再通过各种方式诱导用户注册本站账号，补全信息
• 允许第三方登录，首次注册后，立即注册本站账号，但在此之前做出明确提示

多账号体系

在第三方登录时，用户一般不希望在本站有多个账号，即每用一种第三方登录（QQ、微信、手机、邮箱）就生成一个user_id，多一种账号。当用户用不同第三方登录时，登录的是不同的账号。

除非本站是不需要交互的，类似银行“户头”，或微博这种希望用户账号多，关注人数多的。

而像有数据信息的账户，类似博客，论坛这种有积分、阅读历史、收藏等数据信息时，用户希望能统一共享数据信息。

对于希望账号统一的情况，采用的设计方案：

a.无视小部分用户希望合并不同登录端账户信息的需求；（开发成本低，影响部分用户体验）

b.提供账号合并功能；（开发成本高，用户体验好）

c.第一次第三方登录后强制注册。（开发成本适中，影响部分用户体验）

业务中的注册登录验证方式

一、账号密码登录
账号密码登录方式，用户已经使用很成熟了，外部依赖度低，但是密码简单时，容易被破解，密码复杂时，记忆难度大。

• 个体识别度：低
• 便捷程度：低
• 技术要求：低
• 风险程度：高

二、基础通信登录（手机或邮箱）
随着通信覆盖率的基本饱和及IM的发展，手机号码逐渐取代邮箱成为最通用的验证方式。目前阶段，由于注册登录的便捷性，无需记住密码的特点，采用基础通信方式进行身份验证是最为普遍的。
但是手机号可能长期不用，然后又由运营商分配给另一个用户。因此需要进行补充流程的验证，增加了使用成本。

• 个体识别度：中
• 便捷程度：中
• 技术要求：中
• 风险程度：中

三、证件信息认证（实名、护照、学生证等）
证件作为国家采信的身份校验信息，符合校验信息的基本要求。然而有两个特点限制了他的使用场景，一是敏感性，二是复杂性。

• 个体识别度：高
• 便捷程度：低
• 技术要求：中
• 风险程度：中

四、生物特征（指纹、虹膜、语音音频、人脸识别等
**理论上完美的实现方式。**基本上能够实现实人与网络的连接。现在的问题在于两个点，一是技术手段瓶颈；二是可识别性仍有待开发空间。找到人体上最独一无二的地方，再使用他进行便利的验证。能够实现的话就是验证方式的终极了。目前苹果的指纹登录，腾讯的声音锁，支付宝的人脸识别等功能正是向终极迈进的方向。

• 个体识别度：高
• 便捷程度：高
• 技术要求：高
• 风险程度：低

设计分析

对于不同的产品，应该有不同的设计方案。

如今对于营销类应用，仅需要用户提供微信登录，并在后续吸引用户填写手机号。

对于有独立内容的应用，比如公司网站、政府网站等等，需要用户必须注册本站账号，若第三方登录，则必须再强制注册本站账号。

一、行业

不同的行业，面临的流量与风控的要求不同。如上图所示，不同的行业由于业务场景的不同需要选择不同的注册登录流程。越接近流量导向，则注册登录流程越短（甚至无需注册登录亦能享受服务），注册登录流程后置可能性加大；越靠近风控导向，则注册登录流程越长，注册登录流程后置可能性变小。当公司产生发展方向调整的时候，注册登录流程也需要进行相应调整。

二、公司发展阶段

不同的公司发展阶段，也是一样的道理。发展初期，由于面临巨大的流量压力，对更偏向于选择短平快的，快速搭建账号体系的方式；发展后期，不管是出于业务拓展，为转型准备、精确营销及增加手中数据价值等等的考虑，往往会考虑自建账号体系，使用自己的注册登录流程。

三、具体渠道业务定位

以电商行业举例，APP，PC及H5，外投渠道，这些渠道承载的使命是不同的，因此如果有必要，也应该根据他们的定位进行符合要求的注册登录流程设计，最大化的发挥渠道效果。APP及PC，由于相对来说面向用户主要以成熟用户，老用户为主，功能更加全面，也有包括资产管理等安全要求较高的模块，因此对这些渠道来说，是需要走相对长的注册及登录流程的；至于H5及外投渠道，由于更轻量化，更侧重于引导快速交易，因此更倾向于流程后置，缩短流程，减少用户损耗。

因此需要看下，自己的行业是偏流量导向还是风控导向，公司发展阶段如何，具体渠道的业务形式，才可以从上面不同的账号注册登录形式中，选出最适合自己的方式，再进行逆向流程的补充，UI交互的打磨，形成最适合自己的注册登录流程。

需要说明的一点是，注册登录流程不是一成不变的，在发展的不同阶段，有可能会适当的进行调整。甚至于，在同一阶段，针对不同渠道的需求，也需要灵活处理。如何做好规划，这是用户产品经理的工作重点。

设计实现

综合以上考虑，我认为的数据库表结构设计如下：

个人信息表
person
|id|nickname|avatar|mobile|email|sex|birthday
|1|慕容雪村|http://…/avatar.jpg|mobile|email|男|19980101
本站用户表
user
|id|username|password|department|enabled|disabled_time|password_error_number|is_deleted
|1|zhangsan|password_hash(密码)|123|1|0|0
三方授权表
user_auths
|id|user_id|identity_type|identifier|credential|
|1|1|email|123@example.com|password_hash(密码)
|2|1|phone|13888888888|password_hash(密码)
|3|1|weibo|微博UID|微博access_token

首先用户信息表和用户授权表分开，没什么疑问。
其中用户user_id就是数据库主键，通过user_id与其他表外键关联，账号名username保证全局唯一，用于识别用户。这里并不生成全局独特的user_id，比如UUID生成，或一段连续的数字。也不向前端显示user_id，仅作为系统内部关联所用。

在多企业系统中，账号名username和机构department联合构成全局唯一。

username可以是用户自定义的纯字母，也可以是手机、邮箱，只要唯一就够了，并不做验证。
而手机号，邮箱在个人信息表中由用户自行变更，并不验证真实与否。当需要绑定账号时，才不允许用户随意变更，这时锁定该字段。同理，身份证号实名认证也是如此。

本站用户表唯一用途，就是进行登录，验证和识别身份，获得用户权限。不负责其他任务。

三方授权表唯一用途，就是提供另外的方式进行登录，验证和识别身份，获得用户权限。不负责其他任务。首次注册后，必须强制注册绑定本站账号。

这也很符合项目的生命周期，从项目开发初始只有本站注册方式，当项目发展到一定程度另外提供第三方登录。

最开始只提供账号密码登录，等有资本了，另外提供手机验证码登录。

初始只有后台管理员等有限用户，只需要用户名账号密码登录，后期发展起来，开始有大量用户，只须要在前端限制只能手机或邮箱作为账号名注册即可，不需改表结构。