手摸手实现美团饿了么本地化生活项目CPS分销——设计数据库篇

还没缓过神，已经到了新一年的2月底，敲起键盘的这一刻不禁使用那纯熟的河南英语感叹道How time flies, we are still young? !。生命不止，奋斗不息，我依旧在努力的路上前行，坚持，为大家多产出点有用的东西。新的一年不松懈，一起加油！

回望过去的一年，加了不少开发者交流群，也了解到一些热门的项目，比如年前比较火的合成大西瓜 和 封面红包 等，关于封面红包可以看下我的历史文章，有清晰的讲述。看着那些大佬使用关键字截流等方法为自己的小程序和公众号引来一批用户，确实让人有点羡慕眼红。

但是我觉得无论如何还是要有始有终，在CPS领域再下点功夫完善自己的项目，因为我觉得CPS始终是一个低成本见效快的小项目，计划在新的一年深耕，比如分销，API提供，以及相关的技术知识要点教程输出。

上干货时间到，想搞分销项目，那少不了分销者关联关系，以及如何订单关联等，当然最最重要的是今天要讲的打地基部分，设计核心数据库。

用户表

CREATE TABLE `fenxiao_user` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `pub_open_id` varchar(255) NOT NULL DEFAULT '' COMMENT '公众号平台openid',
  `created_at` datetime NOT NULL,
  `status` tinyint(4) NOT NULL DEFAULT '1',
  `updated_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `taoke_code` varchar(255) NOT NULL DEFAULT '' COMMENT '淘客码',
  `mobile` varchar(255) NOT NULL DEFAULT '' COMMENT '手机号',
  `city` varchar(255) DEFAULT NULL,
  `avatar` varchar(255) NOT NULL DEFAULT '',
  `password` varchar(255) NOT NULL DEFAULT '',
  `nickname` varchar(255) NOT NULL DEFAULT '',
  `gender` tinyint(4) DEFAULT NULL,
  `mini_open_id` varchar(255) NOT NULL DEFAULT '' COMMENT '小程序openid',
  `union_id` varchar(255) NOT NULL COMMENT '公共平台的union_id',
  `visit_code` varchar(255) NOT NULL COMMENT '分销邀请码',
  `visit_h5_link` varchar(255) NOT NULL,
  `vist_mini_qrcode` varchar(255) NOT NULL,
  `user_type` tinyint(4) NOT NULL DEFAULT '1' COMMENT '1普通用户 2是分销用户',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=10046 DEFAULT CHARSET=utf8mb4

简单讲下核心的几个字段

因为项目是基于微信生态的，所以主要推广平台为微信公众号h5和微信小程序,其中三个字段pub_open_id,mini_open_id,union_id分别为微信公众号的openid， 小程序的openid以及打通两者的开发平台上的联合id。这样设计方便后期账户打通。

visit_code字段是邀请码，可以在注册链接上带上用来识别用户之间的邀请关系。
visit_h5_link 和 vist_mini_qrcode 分别是带有邀请码的h5邀请链接以及邀请小程序码图片地址

taoke_code字段是淘客链接生成需要的一个淘客邀请码，可以理解为pid广告位的一个东西

用户邀请关系表

CREATE TABLE `fenxiao_visit_relation` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `visit_user_id` int(11) NOT NULL,
  `visited_user_id` int(11) NOT NULL,
  `level` varchar(255) NOT NULL COMMENT '邀请等级',
  `created_at` datetime NOT NULL,
  `updated_at` datetime NOT NULL,
  `status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '1正常',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=utf8mb4

用户关系表相对来说也不复杂，主要是来找到用户表fenxiao_user里的邀请关系。使用主表里的visit_code邀请码生成的小程序码或者h5邀请链接等注册登录后，可通过visit_code来找到当前注册用户的邀请者的user_id，这里当前被邀请的用户ID是visited_user_id,发起邀请者的用户ID是visit_user_id。

假设我们做了两级分销。当前注册的用户C的邀请者是B，然后去查邀请表有A推荐B注册的，那么我们就可以在邀请关系表里面新增两条记录
|visit_user_id | visited_user_id| level |
| B | C | 1 |
| A | C | 2 |
如上表A邀请过B，B再邀请C，C注册以后就有两条关于C的邀请关系，因为B是直接邀请，所以level = 1 A则是C的间接邀请者 level = 2。

通过上面的表就很容易的去查某个用户的下级以及下下级推荐关系。

分销订单表

CREATE TABLE `fenxiao_order` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `user_id` int(11) NOT NULL,
  `order_status` tinyint(4) NOT NULL,
  `project_id` tinyint(4) NOT NULL,
  `pay_price` int(11) DEFAULT NULL,
  `order_id` varchar(255) DEFAULT NULL,
  `pay_time` int(11) DEFAULT NULL COMMENT '支付时间',
  `origin_profit` int(11) DEFAULT NULL,
  `profit` int(11) DEFAULT NULL COMMENT '订单返佣金额',
  `sms_title` varchar(255) DEFAULT NULL COMMENT '订单标题\n\n订单标题\n\n',
  `quantity` tinyint(4) DEFAULT NULL COMMENT '退款笔数',
  `refund_time` int(11) DEFAULT NULL,
  `refund_profit` int(11) DEFAULT NULL,
  `create_time` int(11) DEFAULT NULL,
  `pid` varchar(255) DEFAULT NULL,
  `promotion_rate` int(11) DEFAULT NULL COMMENT '给用户的比列',
  `origin_rate` int(11) DEFAULT NULL COMMENT '原始比列',
  `created_at` datetime DEFAULT NULL,
  `updated_at` datetime DEFAULT NULL,
  `refund_price` int(11) DEFAULT NULL COMMENT '0',
  `project_type` int(11) DEFAULT NULL,
  `level` tinyint(4) NOT NULL DEFAULT '0',
  `origin_price` int(11) NOT NULL DEFAULT '0' COMMENT '原价',
  `order_user_id` int(11) NOT NULL COMMENT '下单人',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=10333 DEFAULT CHARSET=utf8mb4

这里主要介绍下订单如何生成以及更新的方法

生成的时候往往是提交订单，可以利用CPS平台的订单回调通知方式+定时拉取CPS平台订单列表的方式来生成自己的分销订单表。
无论是回调通知还是订单列表都会有一个携带淘客推广为pid的一个参数，以及订单ID。

然后就可以入库订单相关信息，同样的，我们可以记录订单到底是谁推广的，通过订单中的pid去查找到直接推广的UserID，然后通过UserID查找邀请关系表，分别按照自己设定的每一级别推广分佣比例 为这一系列用户分别生成一条订单记录，user_id是产生订单收益的当前用户ID，order_user_id保存真正直接链接推广下单的用户ID，同样要保存一下邀请表中的level订单列表可以展示出是下级还是下下级出的单。

依旧拿上面的邀请关系来说,C的推广链接下的单
|user_id | order_user_id | level | profit |
| C | C | 0 | 60%|
| B | C | 1 | 20%|
| A | C | 2 | 10%|

通过上面的订单表，我们很容易知道有人通过用户C的推广链接下单，用户A的下下级推广出去成交的，所以可以获得该笔订单的10%推广费。

本作品采用《CC 协议》，转载必须注明作者和本文链接