淺談資料庫使用者表結構設計，第三方登入

　　說起使用者表，大概是每個應用/網站立項動工（碼農們）考慮的第一件事情。使用者表結構的設計，算是整個後臺架構的基石。如果基石不穩，待到後面需求跟進了發現不能應付，回過頭來反覆修改使用者表，要大大小小作改動的地方也不少。與其如此，不妨設計使用者表之初就考慮可擴充性，爭取不需要太多額外代價的情況下一步到位。

　　先前設計：

　　id
　　username
　　password

　　使用者名稱加上密碼，解決簡單需求，留個id作為其他表的外來鍵。當然，那時候密碼還可能是明文儲存，好點的知道md5。

　　後來呢，隨著業務需求的擴充，要加個使用者狀態 status 判斷使用者是否被封禁，註冊時間和註冊IP地址、上次登入時間和IP地址備查（並衍生出登入記錄表，用來判斷是否異地登入等，在此不表），使用者角色/許可權 role （又衍生出使用者角色許可權關係，還是另文討論），業務也需要個人的個人資訊如真實姓名、地址等也一股腦往上新增，現在形成了一個很完整的使用者關係表。

　　id
　　username
　　password
　　realname
　　address
　　…
　　status
　　role
　　register_time
　　register_ip
　　login_time
　　login_ip

　　現在問題來了，進入Web2.0時代，微博開放了第三方網站登入，用微博帳號就能登入我們的網站，老闆說，這個我們得要。加個微博使用者登入表吧，當然，得和我們自己的使用者表關聯，這個微博使用者資訊表如下：

　　id 自增ID
　　user_id 關聯本站使用者ID
　　uid 微博唯一ID
　　access_token
　　access_expire

　　這還不算完，QQ又開放使用者登入了，一下子要接入好多家第三方登入了，只能就著“微博使用者資訊表”繼續加型別加判斷，如果是每個第三方登入都新建一個表，肯定會瘋的。

　　時代變了，進入了移動網際網路時代，怎麼也得支援個手機號登入吧？所以現在每家標配都是：使用者名稱/郵箱/手機號登入，外加一系列微博、微信等第三方登入。表結構如下：

　　使用者表：

　　id
　　username
　　email
　　phone
　　…

　　使用者第三方登入表：

　　id
　　user_id
　　app_type
　　app_user_id
　　access_token
　　…

　　使用者在輸入框輸入使用者名稱/郵箱/手機號和密碼之後，後臺判斷是郵箱、手機號或是使用者名稱，再根據條件查詢是否為特定使用者。這個表結構能夠承載未來一段時間的業務需求了。如果說某天冒出了一個新的登入方式，比如身份證號登入，怎麼辦？繼續在使用者表加欄位？我覺得有更好的選擇。

　　改進版：

　　無論username+password，還是phone+password，都是一種使用者資訊+密碼的驗證形式；再來理解第三方登入，其實它也是使用者資訊+密碼的形式，使用者資訊即第三方系統中的ID（第三方登入一定會給一個在他們系統中的唯一標識），密碼即access_token，只不過是一種有使用時效定期修改的密碼。所以我們把它抽象出了使用者基礎資訊表加上使用者授權資訊表的形式。

　　使用者基礎資訊表 users：

　　id
　　nickname
　　avatar

　　使用者授權資訊表 user_auths：

　　id
　　user_id
　　identity_type 登入型別（手機號 郵箱 使用者名稱）或第三方應用名稱（微信 微博等）
　　identifier 標識（手機號 郵箱 使用者名稱或第三方應用的唯一標識）
　　credential 密碼憑證（站內的儲存密碼，站外的不儲存或儲存token）

　　這個系統最大的特色就是，使用者資訊表不儲存任何密碼，不儲存任何登入資訊（如使用者名稱、手機號、郵箱），只留有暱稱、頭像等基礎資訊。所有和授權相關（且基本前端展示無關的），都放在使用者資訊授權表，使用者資訊表和使用者授權表是一對多的關係。說起來太抽象，show you 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|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|

　　說說具體處理，使用者發來郵箱/使用者名稱/手機號和密碼請求登入的時候，依然是先判斷型別，以某使用者使用了手機號登入為例，使用 SELECT * FROM user_auths WHERE type=’phone’ and identifier=’手機號’ 查詢條目，如有，取出並判斷password_hash(密碼)是否和該條目的credential相符，相符則通過驗證，隨後通過user_id獲取使用者資訊。

　　如果使用第三方登入，則只要判斷 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，該微博已經在本站存在，但當前使用者已經登入並關聯的是另一個微博帳號，作何處理？切換使用者或是報錯？（畫一個流程圖能更好描述這個問題）這個問題與採用的資料結構沒有關係，只是在做第三方帳號註冊登入時遇到的各種情況，在此一併整理。