淺談第三方登錄用戶表結構設計方案


國民兩大流量入口,大家不說也想到了,分別是微信和QQ。所以為了方便獲取用戶來源都對接了微信登錄或者QQ登錄,這一類型的第三方登錄入口。今天就以對接微信登錄、QQ登錄與蘋果登錄。來說說對第三方用戶體系與我方系統用戶體系的對接的一些可行性方案。

0x01:我方用戶表與第三方用戶表同為一張表

一般系統都會有自己的一套用戶系統,主管用戶的注冊、登錄、登出、權限等。比如我方用戶系統的用戶表 t_user 大致包含如下一些字段:

id:主鍵id

username:用戶名

age:用戶年齡

mobile:手機號號碼

password:登錄密碼

source_from:用戶來源

auth_flag:用戶認證狀態

create_date:注冊日期

以上是最簡單的一些用戶信息了,那現在要對接第三方用戶體系。比如,對接微信。這是最普遍的第三方用戶對接了。因為這種方案我方用戶表與第三方用戶表在一張表里,所以需要在用戶表 t_user 中添加一個標識,表示我方用戶與微信用戶唯一綁定的字段,一般使用微信的 openid,這樣的話需要修改表,添加一個wx_openid字段

id:主鍵id

username:用戶名

age:用戶年齡

mobile:手機號號碼

password:登錄密碼

source_from:用戶來源

auth_flag:用戶認證狀態

wx_openid:微信的openid

create_date:注冊日期

如果有要對接 QQ 和 Apple,這樣的話有的修改表:

id:主鍵id

username:用戶名

age:用戶年齡

mobile:手機號號碼

password:登錄密碼

source_from:用戶來源

auth_flag:用戶認證狀態

wx_openid:微信openid

qq_openid:qq openid

appleid:蘋果id

create_date:注冊日期

這種方案設計簡單,只要對接一個第三方,就是需要對原來的用戶表進行修改,如果對接的第三方過多,用戶表就慢慢的變得非常臃腫。從另外一個方面看,對原來用戶代碼進行修改。

0x02:我方用戶表一張表、第三方用戶表一張表

由於第一種方案如果對接額外的第三方需要不斷的修改用戶,以及原來的代碼邏輯,對生產可能造成不確定因素。所以可以采取另外一種方案我方用戶表一張表、第三方用戶表一張表這種方案。比如用戶表 t_user 設計大致如下:

id:主鍵id

username:用戶名

age:用戶年齡

mobile:手機號號碼

password:登錄密碼

source_from:用戶來源

auth_flag:用戶認證狀態

create_date:注冊日期
  • 第三方用戶表 t_third_acount 設計大致如下:
user_id:對應 t_user的用戶id

third_unique_acount:第三方唯一用戶id,可以是微信的openid,可以是QQ的openid,抑或蘋果id

type:標識第三方類型,這里規定1.代表微信,2.代表QQ,3.代表蘋果

bind_flag:標識是否綁定,1綁定,2解綁

create_date:綁定時間

這樣設計的話,以后一般不需要修改表結構;但是新添加第三方用戶對接時,還是免不了需要對原來的代碼邏輯做改動。

0x03:我方用戶表一張表、第三方用戶表多張表

基於第二種方案,第三方用戶表使用了一個 type 字段來表示不同的第三方用戶體系,通過不斷的新增不同的枚舉來標識不同的第三方。所以可以去除這個字段,然后不同的第三方使用不同的表來標識。比如用戶表 t_user 設計大致如下:

id:主鍵id

username:用戶名

age:用戶年齡

mobile:手機號號碼

password:登錄密碼

source_from:用戶來源

auth_flag:用戶認證狀態

create_date:注冊日期

+ 微信用戶體系的表 t_wechat_acount 設計大致如下如下:

user_id:對應 t_user的用戶id

wx_openid:微信的openid

bind_flag:標識是否綁定,1綁定,2解綁

create_date:綁定時間
  • QQ用戶體系的表 t_qq_acount 設計大致如下如下:
user_id:對應 t_user的用戶id

qq_openid:QQ的openid

bind_flag:標識是否綁定,1綁定,2解綁

create_date:綁定時間
  • 蘋果用戶體系的表 t_apple_acount 設計大致如下如下:
user_id:對應 t_user的用戶id

appleid:蘋果id

bind_flag:標識是否綁定,1綁定,2解綁

create_date:綁定時間

這些方案的話,第三方用戶表就有點膨脹的意思,系統對接了多少個第三方用戶體系,就有多少張第三方用戶體系表。

以上三種方案,屬誰最優,不下定論。我覺得根據項目的要求,滿足自身項目的需要,符合可用的業務場景的方案就是最優解。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM