用户系统第三方登录设计
最近用户系统要升级，开始接入第三方登录，目前看来接入的第三方还不是一般的多，大致数了一下，微信、支付宝、钉钉、淘宝。。。
现有的用户模型显然是不支持这种扩展的，首先动的就是数据库，目前User表很单一，里面存的只是一些常规的用户数据，那么如何改造呢？
Google大法没什么不好的，取长补短，吸收来自大千世界的优秀知识。
下面这篇文章是在掘金发现的，称得上鞭辟入里，读完让人豁然开朗。
文章中并没有讲数据库怎么设计，但是揭示了第三方登录的由来，以及一些优劣势，这对于设计数据库的帮助是巨大的。
简要的抄录一下结论
目前第三方登录通常有两种设计思路
-
1、将第三方登录看成一种登录方式，使用第三方登录的前提是，你先要有一个账户。
缺点：当用户没有账户，直接使用第三方登录时，你只能提示他先去注册账户。但在用户看来，就是欺骗，容易引起用户的反感。
优点：当用户账户绑定了第三方账号后，用户就在也不用记住密码了，完全可以通过各个熟悉的第三方账号登录系统。 -
2、将第三方登录，看成一个独立的用户
优点：没有注册流程，容易吸引用户，由于是第三方直接登录，也不需要考虑用户会忘记密码
缺点：一个人容易产生多个账户，用户的行为容易分散到多个账户中，增加了系统的复杂性，某些情况下还会影响用户的产品体验。
通篇看下来，第三方登录并没有想象中的那么美好，第一种方式也就仅仅解决用户忘记密码的问题，注册时还会引起用户反感。第二种方式虽然能起到吸引用户的作用，但却增加了系统的复杂性，某些情况下还会影响用户的产品体验。
第二种方式在初期对于用户很友好，不会引起任何反感，但是在后期如果出现同步数据的情况，这将是灾难性的!
文中引用了简书的例子，目前简书就是采用了第二种登录方式，每种第三方登录方式都会产生一个用户。
在简书中，如果你想将多个第三方登录产生的账户合并成一个账户，首先要使用手机号或邮箱注册一个传统账户，然后将你第三方登录的账户中所有发表的文章先备份到本地，然后全部删除，还要将账户中的钱全部用完。之后让系统将你的第三方账户彻底删除。之后再用传统的账户重新绑定第三方账号。最后重新上传文章。
很显然，同步数据的麻烦程度出乎意料。
到底为止，数据库的设计方案就很明朗了，在增加一张user_login_auth表
里面存储第三方登录信息，user表和user_login_auth表就是一对多的关系了。
👍