0x01：我方使用者表與第三方使用者表同為一張表

一般系統都會有自己的一套使用者系統，主管使用者的註冊、登入、登出、許可權等。比如我方使用者系統的使用者表 t_user 大致包含如下一些欄位：

id：主鍵idusername：使用者名稱age：使用者年齡mobile：手機號號碼password：登入密碼source_from：使用者來源auth_flag：使用者認證狀態create_date：註冊日期

以上是最簡單的一些使用者資訊了，那現在要對接第三方使用者體系。比如，對接微信。這是最普遍的第三方使用者對接了。因為這種方案我方使用者表與第三方使用者表在一張表裡，所以需要在使用者表 t_user 中新增一個標識，表示我方使用者與微信使用者唯一繫結的欄位，一般使用微信的 openid，這樣的話需要修改表，新增一個wx_openid欄位

id：主鍵idusername：使用者名稱age：使用者年齡mobile：手機號號碼password：登入密碼source_from：使用者來源auth_flag：使用者認證狀態wx_openid：微信的openidcreate_date：註冊日期

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

id：主鍵idusername：使用者名稱age：使用者年齡mobile：手機號號碼password：登入密碼source_from：使用者來源auth_flag：使用者認證狀態wx_openid：微信openidqq_openid：qq openidappleid：蘋果idcreate_date：註冊日期

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

0x02：我方使用者表一張表、第三方使用者表一張表

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

id：主鍵idusername：使用者名稱age：使用者年齡mobile：手機號號碼password：登入密碼source_from：使用者來源auth_flag：使用者認證狀態create_date：註冊日期

第三方使用者表 t_third_acount 設計大致如下：

user_id：對應 t_user的使用者idthird_unique_acount：第三方唯一使用者id，可以是微信的openid，可以是QQ的openid，抑或蘋果idtype：標識第三方型別，這裡規定1.代表微信，2.代表QQ，3.代表蘋果bind_flag：標識是否繫結，1繫結，2解綁create_date：繫結時間

這樣設計的話，以後一般不需要修改表結構；但是新新增第三方使用者對接時，還是免不了需要對原來的程式碼邏輯做改動。

0x03：我方使用者表一張表、第三方使用者表多張表

基於第二種方案，第三方使用者表使用了一個 type 欄位來表示不同的第三方使用者體系，透過不斷的新增不同的列舉來標識不同的第三方。所以可以去除這個欄位，然後不同的第三方使用不同的表來標識。比如使用者表 t_user 設計大致如下：

id：主鍵idusername：使用者名稱age：使用者年齡mobile：手機號號碼password：登入密碼source_from：使用者來源auth_flag：使用者認證狀態create_date：註冊日期

微信使用者體系的表 t_wechat_acount 設計大致如下如下：

user_id：對應 t_user的使用者idwx_openid：微信的openidbind_flag：標識是否繫結，1繫結，2解綁create_date：繫結時間

QQ使用者體系的表 t_qq_acount 設計大致如下如下：

user_id：對應 t_user的使用者idqq_openid：QQ的openidbind_flag：標識是否繫結，1繫結，2解綁create_date：繫結時間

蘋果使用者體系的表 t_apple_acount 設計大致如下如下：

user_id：對應 t_user的使用者idappleid：蘋果idbind_flag：標識是否繫結，1繫結，2解綁create_date：繫結時間

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

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