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

本站系统的用户登录设计

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

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

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

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

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

  • 网站还是需要用户名,用于区别内部用户。
  • 当提及某个用户时,邮箱和手机号,用户可能不想公开。而提及昵称时,昵称可以重复,不能作区分。
  • 用户名一旦选定不允许更改,邮箱和手机号作为第三方的系统,应该允许更改。
    数据库表设计:基于业务场景的用户表的设计_第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作为登录本站系统的凭证,并获得附带的信息(昵称、头像等)。

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

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

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

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

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

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

解决方法:

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

数据库表设计:基于业务场景的用户表的设计_第2张图片

多账号体系

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

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

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

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

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

b.提供账号合并功能;(开发成本高,用户体验好)

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

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

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

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

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

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

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

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

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

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

设计分析

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

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

对于有独立内容的应用,比如公司网站、政府网站等等,需要用户必须注册本站账号,若第三方登录,则必须再强制注册本站账号。
数据库表设计:基于业务场景的用户表的设计_第3张图片

一、行业

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

二、公司发展阶段

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

三、具体渠道业务定位

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

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

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

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

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

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

你可能感兴趣的:(数据库相关技术,数据库,java,开发语言)