手摸手實現美團餓了麼本地化生活專案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 協議》，轉載必須註明作者和本文連結

技術變現，讓程式碼多一份價值

手摸手實現美團餓了麼本地化生活專案CPS分銷——設計資料庫篇

使用者表

使用者邀請關係表

分銷訂單表

相關文章