## 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 -- ---------------------------- ``` [用户消息通知系统 · 产品设计 · 看云](https://www.kancloud.cn/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笔记 · 看云](https://www.kancloud.cn/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