## awesomes-tables  那些極好的表設計 * * * * * #### 短信驗證碼 表 短信驗證碼表（id，標識名/業務標識，驗證碼，手機號碼，創建時間，發送時間，發送狀態，有效時間，錯誤驗證次數，狀態。頁面key？） * * * * * #### 用戶表 ```sql -- ---------------------------- -- Table structure for `user` -- ---------------------------- DROP TABLE IF EXISTS `user`; CREATE TABLE `fn_admin` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT '管理員用戶ID', `nickname` char(16) NOT NULL DEFAULT '' COMMENT '昵稱', `avatar` varchar(500) NOT NULL DEFAULT '' COMMENT '頭像', `password` char(40) NOT NULL DEFAULT '' COMMENT '用戶密碼', `salt` char(32) NOT NULL DEFAULT '' COMMENT '用于保護用戶密碼安全的鹽值', -- 這個用戶郵箱和手機是唯一的，但是有的人開始并沒有綁定郵箱或手機，所以也不能為空串，不然唯一沖突，所以只能允許為空null了，并且默認為null `email` char(32) NULL DEFAULT NULL COMMENT '用戶郵箱（可用作登錄名）', `mobile` char(15) NULL DEFAULT NULL COMMENT '用戶手機（可用作登錄名）', `login` int(10) unsigned NOT NULL DEFAULT 0 COMMENT '登錄次數', `create_ip` bigint(20) unsigned NOT NULL DEFAULT 0 COMMENT '注冊IP', `create_time` int(10) unsigned NOT NULL DEFAULT 0 COMMENT '注冊時間', `last_login_ip` bigint(20) unsigned NOT NULL DEFAULT 0 COMMENT '最后登錄IP', `last_login_time` int(10) unsigned NOT NULL DEFAULT 0 COMMENT '最后登錄時間', `update_time` int(10) unsigned NOT NULL DEFAULT 0 COMMENT '更新時間', `status` tinyint(4) unsigned NOT NULL DEFAULT 0 COMMENT '狀態', PRIMARY KEY (`id`), UNIQUE KEY `nickname` (`nickname`) USING BTREE, UNIQUE KEY `email` (`email`) USING BTREE, UNIQUE KEY `mobile` (`mobile`) USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='用戶 表'; -- ---------------------------- -- Records of user -- ---------------------------- ``` * * * * * #### 系統通知消息表（通知類消息而非廣播類消息） ```sql -- ---------------------------- -- table structure for `a_system_notification` -- ---------------------------- DROP TABLE IF EXISTS `a_system_notification`; CREATE TABLE `a_system_notification` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `recipient` int(11) unsigned NOT NULL DEFAULT 0 COMMENT '接收者 用戶ID', `title` varchar(64) NOT NULL DEFAULT '' COMMENT '消息標題', `content` text NULL COMMENT '消息內容', `payload` text NULL COMMENT '載荷/參數，可攜帶業務方數據，如綁定通知時攜帶下級的用戶信息，在通知模板中會用到', `create_time` int(11) unsigned NOT NULL DEFAULT 0 COMMENT '發送時間', `is_red` tinyint(4) unsigned NOT NULL DEFAULT 0 COMMENT '是否閱讀了', `type` tinyint(4) unsigned NOT NULL DEFAULT 0 COMMENT '消息類型：0-系統普通消息，1-新人注冊通知，2-下級成功綁定通知', primary key (`id`) ) engine=innodb AUTO_INCREMENT=1 default charset=utf8 COMMENT='系統通知消息 表'; -- ---------------------------- -- records of a_system_notification -- ---------------------------- ``` [用戶消息通知系統 · 產品設計 · 看云](http://www.hmoore.net/xiak/product/590024) （只有一條母消息，其它為消息狀態，這樣的消息為廣播消息。廣播類消息要用這樣的母消息。） >[tip] 不要直接將業務數據給到消息載荷，不要讓它(消息處理/消息獲取對象)自己去解析，它沒這個義務去幫你解析業務數據，請直接給完整的數據，比如用戶信息就不要只給uid，訂單數據就不要只給訂單id，狀態就不要只給狀態值，狀態文字也要一并解析好再給它。 > > 對于業務通知類消息，消息創建時間不可能在業務時間之前（這個細節不要忽視）。因為消息通知是由于業務動作產生的。 * * * * * #### 信息流 信息流系統，業務表，信息表 信息類型 有的類型是沒有對應業務的 比如點贊 說說有業務表，業務id，用戶，消息表 信息id，消息接受者，是否已讀 業務表可能是人，文章，項目，相冊等，具體根據信息類型來確定，比如點贊文章，關注項目，關注人，點贊相冊 [feed留，單聊群聊，系統通知，狀態同步，到底是推還是拉？](https://mp.weixin.qq.com/s/54yEWWet9mFztv1fO_GTqQ) > 【feed & flow】重要消息用推，不重要消息用拉，另外qq只有開會員才有好友上線提醒吧，所以根據用戶可以區分對待。消息閱讀狀態肯定是要有的，姚晨發一條微博，表中只有一條消息記錄，但是n個充錢粉絲，都各自有一條對應記錄(消息表id，接受者，發送時間，閱讀狀態)，這樣就可以記錄用戶閱讀狀態了，而無需存n條消息。消息推送放到隊列里面去就可以了 [系統通知，居然有人使用拉取](https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651961154&idx=1&sn=277f6ec612555bf5a95585e9a161bb5f&chksm=bd2d029e8a5a8b884c9855b8e315a697a0e8eccf227fb36395334d140dd9eebf2489e99862d3&scene=21#wechat_redirect) [狀態同步，究竟是推還是拉？](https://mp.weixin.qq.com/s/oQ4K4zMRCGRtqly412U_TQ) * * * * * #### 第三方oauth ~~~ OAuth： 網絡釋義 OAuth: OAuth OpenID OAuth: 提供像第三方登錄服務 OAuth authentication: OAuth認證 Auth： 基本翻譯 n. (Auth)人名；(德、匈、英)奧特 abbr. 自生的（authentic）；授權的（authorized） 網絡釋義 Auth: 聯盟 GFA Auth: 身份認證系統 Group auth: 組認證 ~~~ oauth_platform_subject（平臺主體，類似于微信開放平臺，可滿足某些業務場景） oauth_platform oauth_account oauth_connect oauth_user_bind oauth_access_token（應用授權令牌 表） oauth_user_access_token（用戶授權訪問令牌 表） ~~~ 平臺主體（id，name） 第三方oauth平臺表（id，平臺名，平臺標識，logo，創建時間，字段json）QQ，微信公眾號，微信小程序，微信企業號（跟接口有關，平臺都對應有接口文件，這個數據比較穩定，除非第三方平臺接口發生變化了，此時也要跟著升級接口） oauth賬號表（id，平臺id，數據json，name，創建時間，是否啟用，是否支持unionid，是否為oauth賬號/一個平臺只能有一個oauth賬號，是否開啟URL響應，響應接入狀態，最后響應時間，關聯的平臺中心）（創建后，系統正式運行后就不能輕易更改了，因為oAuth用戶數據已經生成了）（2 3 唯一索引） oauth_connect（id，oauth賬號id，openid，unionid，return_json接口返回的用戶信息，update_time）2 3 唯一索引 oauth_user_bind（id, oauth_connect_id，user_id，bind_time）2 3 唯一索引 user oauth_access_token（oauth賬號id，access_token，refresh_token，expires_in，update_time） oauth_user_access_token（oauth_user_bind_id，access_token，refresh_token，expires_in，update_time） ~~~ >[danger] **我們認為：一個人為一個用戶，一個手機號碼即為一個用戶，一個用戶對應一個社交賬號（一個人在一個社交平臺上只有一個賬號）**（這個規則很重要，要嚴格檢查，不然可能會出現不符合正常邏輯的問題）。由于unionid的出現，所以一個user不再是只有一個openid了（可以一對多的關系）。而除了微信，其它第三方沒有提供unionid，所以一個用戶只能綁定一個oauth_account。 > ><del>（其實即使沒有unionid其實我們也可以實現一個用戶綁定多個oauth_account）（實現方式：已登錄狀態下，`post: bind.php token oauth_account_id; ；跳轉；響應；換取用戶信息；綁定` 就可以了）。</del> > 不行，這樣可能出現用戶綁定一個平臺下的多個不同社交賬號！所以除了微信這樣的支持unionid的平臺外，其它的都不能這樣，用戶只能綁定同一個平臺下的一個賬號。 > 一般來說，一個公司就一個公眾賬號平臺，但是也存在一個公司多個公眾號的情況，所以要求用戶綁定多個也可以，對于用戶來說就是綁定你的多個公眾平臺（一種下面的多個賬戶，如綁定京東微信，京東金融，發生交易時你會收到兩個公眾號的提醒，不過一般對于用戶來說，就只綁定一個主的，就是京東這個公眾號），這樣就可以多個公眾號向用戶推送信息了。 參考：[賬戶授權相關 · php筆記 · 看云](http://www.hmoore.net/xiak/php-node/638595)  * * * * * #### 第三方支付平臺 payment_platform payment_account ~~~ 第三方支付平臺表（id，平臺名，平臺標識，logo，創建時間，字段json）微信支付，支付寶，京東支付（跟接口有關，平臺都對應有接口文件） 支付賬號表（id，平臺id，數據json，name，創建時間，是否啟用，是否默認/一個平臺只能有一個默認的——被作為支付渠道，關聯的oauth_account_id）（2 3 唯一索引）（有時有一些聯系，可以關聯oauth_account，以滿足某些業務邏輯） ~~~ * * * * * #### 用戶關注記錄表 user_subscribe_record（user_id，oauth_account_id，event，create_time） * * * * * #### 用戶關注狀態表 user_subscribe_status（user_id，oauth_account_id，subscribe） （關注不是綁定） * * * * * #### 用戶賬號綁定信息 綁定郵箱，綁定手機號碼，綁定時間，時間太長了就要提醒用戶重新驗證。 user_account_bind_info（email，email_bind_status，email_bind_time，mobile，mobile_bind_status，mobile_bind_time，user_id） 用戶表需要反三范式，存儲郵箱和手機號碼。 * * * * * ### 用戶會話上下文表 在無session概念的服務里充當session，儲存用戶會話中上下文信息。 **（注意這并不是session表哦）** （id，user_id，json_data） * * * * * ### 鎖 用表來一個鎖。 locks（lock_name） 復雜一點的可以實現信號量 locks（lock_name，semaphore，current_semaphore，status） （要使用支持行鎖的存儲引擎 Innodb） * * * * * ### 進程狀態表 （進程ID，進程標識，當前狀態，上次運行時間，運行次數，備注，……） * * * * *   * * * * * last update：2018-6-22 12:37:24