VipSystem Pro 插件数据表设计概述

千年骚狐
千年骚狐
千年骚狐
6
文章
0
评论
2020年6月8日 评论 503 7275字

VipSystem Pro 插件在安装过程中,在数据库会创建许多数据表。考虑到未来的可开发性及数据的优化和管理,所以对数据表做了细分归类。共计13张数据表。

数据表前缀被打码,固定为“前缀_vs_表名”的表名格式。若您想彻底删除插件的数据,只需要删除包含“_vs_”关键字的数据表即可。

订单类数据表(商品购买订单/充值订单/VIP购买订单等)的创建流程,分为两步。当用户点击购买按钮时,会创建对应数据到表中,所以有一个下单时间。当用户完成付款时,会仅修改订单的状态,所以有一个付款时间。当用户仅创建了订单,但未及进行支付,那么订单也会保留,只不过状态为未支付或已过期。这样做的好处是用户付款时从第三方接口的返回数据中不包含订单的详细信息,很好的保证了数据的安全不被篡改。

你可能不理解上一段话的内容,请接着看下方的具体表结构和字段,也许会帮助你更好的理解插件的工作流程。

各个数据表的内容具体如下:

1. 前缀_vs_options:选项设置存储表

用于存储VipSystem Pro插件中各种选项的设置数据。

和wp_options格式一样,组成字段:

  1. 一序号(table_id)
  2. 键名(option_name)
  3. 键值(option_value)
  4. 更新时间(update_time)

在配置文件中,有部分设置是和表中的数据重复的。当你在手动修改编辑这个表时,确保配置文件里是遵循数据表的设置。否则数据表中的内容修改不起作用。

2. 前缀_vs_users:用户资产存储表

当用户购买订单,或充值时,才会将wp_users表中的用户信息搬迁到这里,并加入当用用户的资产内容。

默认第一次使用时,该表为空。该表仅包含具有虚拟币交易的用户。并不是所有wp_users表中的用户。

表字段:

  1. 唯一序号(table_id)
  2. 用户ID(user_id)
  3. 绑定手机号(bind_telephone)
  4. RMB充值所得虚拟币(user_rmb_recharge)
  5. 积分(user_integral_assets)
  6. 其他充值到虚拟币(user_other_recharge)
  7. 虚拟币总消费(user_consumption)
  8. 积分总消费(user_integral_consumption)
  9. 当前用户生效的VIP类型(user_vip_type)
  10. VIP结束时间(user_vip_end_time)
  11. VIP允许下载次数(user_vip_down_limit)
  12. 虚拟币提现到账类型(cash_withdrawal_type)
  13. 提现转账验证用户姓名(cash_withdrawal_name)
  14. 推广上线用户(promote_users)
  15. 提现转账二维码路径(cash_withdrawal_account)
  16. 用户权限分组(user_group)
  17. 最后更新时间(user_last_modify_time)

其中部分列目是已经规划好的未来要加入的功能。比如:

第3项,绑定手机号。用于手机号登录、找回密码、通知等。

第5项,积分系统。留在未来做积分推广营销的预留数据位置

第16项,用户权限分组。用于未来做多个管理人员的权限划分,可以用于多人分权管理网站数据。

用户的资产分为两类,一类是RMB充值到虚拟币。另一类是充值卡、管理员充值等。为了将来统计网站的真实营收数据预留数据位置。

3. 前缀_vs_order:订单记录存储表

用与商品购买的记录,包括VIP购买。一个订单中可以包含多个商品,这需要开启购物车功能,支持批量付款。每一笔付款代表一个订单。

表字段:

  1. 唯一序号(table_id )
  2. 订单购买的用户ID(user_id)
  3. 购买的用户session会话控制(session_ID)
  4. 系统生成的订单号(order_number)
  5. 订单中每个商品名称(goods_title)
  6. 订单中每个商品的单价(goods_price)
  7. 订单中每个商品购买数量(purchase_quantity)
  8. 订单虚拟币付款价格(payment_price)
  9. 付款方式(payment_type)
  10. 订单的优惠信息(preferential_strategy)
  11. 订单中每个商品/文章ID(goods_id)
  12. 订单中每个商品所选择的套餐(set_meal)
  13. 每个商品中的发卡内容(grant_card_content)
  14. 订单备注信息(order_mark)
  15. 下单时间(order_time)
  16. 付款时间(payment_time)
  17. 确认时间(confirm_time)
  18. 收货信息(receiving_info)
  19. 订单支付状态(order_state)
  20. 订单中每个商品的作者ID(author_id)
  21. 下单用户的客户端IP地址(client_IP)

订单数据表是VipSystem Pro插件中的重要数据存储表。用户的所有虚拟币消费记录都会存在此处。并且同一用户的“订单付款金额”的总和是需要和用户资产表中“虚拟币消费总额”匹配,否则该用户的虚拟币将判断为异常。

规划时,也考虑到未来将开发实体物品的销售,所以也预留了第17项“确认时间”,也就是确认收货的时间。以及第18项,收货地址的数据接口。

第3项,用户session会话控制信息。存储当前用户的订单数据,并对订单信息进行加密的秘钥。当用户下单购买商品时,订单信息不仅会保存在数据表,也会存储在session会话控制中。在支付及下载时,会验证这两个地方的数据是否匹配。防止黑客篡改订单信息,保障订单的安全。

第4项,商品购买订单号。订单号有一定的规则,就是前方的英文字母。具体规则描述写在使用手册中(https://vipsystem.pro/docs/vipsystem-pro-2020-manual#sales_data

第19项,订单支付状态。值为0表示未支付、1表示已支付、2表示已过期。

4. 前缀_vs_recharge:用户充值记录表

记录用户的充值等数据,如果系统开启了“直接扫码支付”功能,则在创建商品购买订单的同时,也会创建对应金额的充值记录。

表字段:

  1. 唯一序号(table_id)
  2. 充值用户ID(user_id)
  3. session会话控制信息(session_ID)
  4. 系统生成的充值订单号(system_order_num)
  5. 第三方返回的订单号,支付宝/微信交易订单号(return_order_num)
  6. 到账虚拟币金额(price)
  7. 充值RMB金额(rmb_price)
  8. 充值订单备注(marks)
  9. 订单状态(order_state)
  10. 下单时间(system_order_time)
  11. 付款时间(pay_time)
  12. 充值方式(recharge_type)

第2项,session会话控制。和商品购买订单中的session机制一样,用于对比数据表中存储的信息和session中的信息是否一致,防止黑客篡改。

第4项,充值订单号。订单号有一定的规则,就是前方的英文字母,具体我写在使用手册中了(https://vipsystem.pro/docs/vipsystem-pro-2020-manual#recharge_data

第5项,第三方返回的订单号。是支付宝或微信充值时,他们所返回的交易订单号。用户核对支付宝或微信的充值金额是否与网站到账金额匹配。可以直接查询到他们的交易记录。

如果网站开启了“直接扫码支付”功能,当用户购买商品/VIP时,使用支付宝/微信直接扫码支付时,会同时创建商品购买记录订单,和充值订单。以确保用户资产表中记录的“虚拟币到账金额”和充值记录中同一用户的“充值金额”总和匹配。否则判定用户资产异常。

5. 前缀_vs_vip:VIP购买记录

当用户购买VIP产品时,保存购买记录到该表中。同时也会更新用户资产数据表中VIP相关的字段的值。

表字段:

  1. 唯一序号(table_id)
  2. 购买VIP的用户ID(user_id)
  3. 订单号(order_num)
  4. VIP产品价格(transaction_price)
  5. 备注信息(remarks)
  6. VIP类型(vip_type)
  7. VIP到期时间(closing_date)
  8. 下单时间(order_time)
  9. 付款时间(pay_time)
  10. 获得方式(acquisition_method)

VIP购买记录表仅作为历史记录,用于用户中心里显示当前用户的VIP购买记录,以及后台VIP产品设置中的每个VIP的购买记录。

修改这个表中的内容,并不会影响某个用户当前生效的VIP。仅修改了历史记录。如果您想手动修改某个用户当前生效的VIP记录,需要修改“前缀_vs_users”表中的内容

6. 前缀_vs_card:充值卡存储表:

用于卡券功能中的卡券数据存储,包含充值卡、优惠券、折扣券等。

表字段:

  1. 唯一序号(table_id)
  2. 卡券类型(card_type)
  3. 卡密(code)
  4. 卡券面值/折扣数值(price)
  5. 卡券备注信息(marks)
  6. 优惠券/折扣券应用的订单号(order_num)
  7. 卡券有效期(validity)
  8. 创建时间(create_time)
  9. 卡券被使用时间(activate_time)
  10. 卡券使用人ID(activate_user_id)
  11. 卡券的持有者ID(holder_id)
  12. 卡券获取方式(create_type)

未来计划的卡券也会有系统内的随机赠送,所以有预留卡券的持有者ID,区分卡券的使用人和持有人。并非简单的只有管理员后台生成。该功能已在计划中。

第6项,订单号。用于记录“优惠券”和“折扣券”的使用订单号,方便查找该卡被用于那个订单中。

7. 前缀_vs_collection:文章收藏存储表

用户中心,商品收藏中的收藏商品记录。

表字段:

  1. 唯一序号(table_id)
  2. 收藏用户(user_id)
  3. 文章作者(author_id)
  4. 商品/文章ID(goods_id)
  5. 备注内容(marks)
  6. 收藏时间(update_time)

本来是不用单独为收藏的商品创建表,只是为了考虑到未来可能用户需要为收藏的文章添加自己的关键字或描述,如果网站的商品很多,有部分用户收藏了许多内容,可以由用户自定义创建收藏文章的分组。这样方便用户查找,是个不错的体验,所以留了这么一个表。

8. 前缀_vs_stock:发卡系统数据存储表

发卡系统是将一组有字符串组成的卡密,发不同的卡密字符串给购买的用户。简单理解就是同一商品每个用户购买的卡密不同。用于出售游戏充值卡等内容。

发卡系统是在后台先创建由多个字符串组成的卡密队列。然后再发布文章时,选择需要出售的卡密队列即可。并非常规理解的方式,在发布文章时创建卡密队列。这样做的好处是可以分开管理卡密队列和文章。

表字段:

  1. 唯一序号(table_id)
  2. 卡密队列的标识(stock_name)
  3. 购买用户ID(user_id)
  4. 卡密内容(stock_password)
  5. 购买时间(buy_time)

该表记录了每一个卡密的购买用户及购买时间

9. 前缀_vs_shop_cart:购物车存储表

当用户加入商品到购物车时,商品数据会存储在这个表中。用户付款后,该表中对应的商品将被删除。是一个及存及删的表。

表字段:

  1. 唯一序号(table_id)
  2. 加入购物车的用户ID(user_id)
  3. 商品作者ID(author_id)
  4. 商品/文章ID(goods_id)
  5. 选购套餐信息(buy_info)
  6. 商品价格(goods_price)
  7. 备注(marks)
  8. 加入购物车时间(update_time)

10. 前缀_vs_distribution_user:分销系统商户信息存储表

该表用于存储分销系统中,入驻的商户信息。

表字段:

  1. 唯一序号(table_id)
  2. 用户ID(user_id)
  3. 认证手机号(bind_phone_number)
  4. 最近一次短信验证码(code)
  5. 最近一次验证码发送时间(code_time)
  6. 商户KEY(merchant_key)
  7. 分销策略标识(distribution_type)
  8. 所得总佣金(total_commission)
  9. 佣金支出(expense_commission)
  10. 二级分佣伙伴ID(second_level_rebate_partner)
  11. 三级分佣伙伴ID(third_level_rebate_partner)
  12. 商户状态(state)
  13. 备注信息(remarks)
  14. 商户数据更新时间(update_time)
  15. 商户入驻时间(create_time)

关于分销系统的玩法,我写在了使用手册中(https://vipsystem.pro/docs/vipsystem-pro-2020-manual#vip_time_limit

第10、11项,二三级分佣伙伴。为当前用户的上线推广人。当前用户的客户付款后,当前用户为一级分佣。

分销系统中创建的分佣策略,包含的一二三级返佣比率,该数据存储在“前缀_vs_options”数据表中,键名为“DSP_product_%”,其中百分号代表数字。

11. 前缀_vs_distribution_rebate_record:分销系统商户返佣记录存储表

该表用于存储每个商户的返佣历史记录。

表字段:

  1. 唯一序号(table_id)
  2. 商户/用户ID(user_id)
  3. 客户ID(client_id)
  4. 需要返佣的订单号(order_number)
  5. 客户的支付金额(payment_price)
  6. 客户的支付方式(payment_type)
  7. 返佣比率(rebate_rate)
  8. 返佣金额(rebate_price)
  9. 客户关系(customer_relations)
  10. 链接标识(links_label)
  11. 备注(remarks)
  12. 返佣时间(update_time)

表字段中用户表示当前商户对应的用户ID,客户表示通过当前商户创建的推广链接访问网站并支付的用户。

包含了客户的订单基本信息,以及商户创建推广链接的标识信息。用于记录客户是通过该商户的哪一个链接进行支付的。方便商户去统计推广链接的部署情况。

12. 前缀_vs_withdrawal_management:佣金提现数据存储表

用于商户进行佣金提现的记录。

表字段:

  1. 唯一序号(table_id)
  2. 提现商户/用户ID(user_id)
  3. 提现订单号(order_number)
  4. 认证手机号(bind_telephone)
  5. 提现验证姓名(cash_withdrawal_name)
  6. 提现金额RMB(withdrawal_price_rmb)
  7. 商户的提现收款账户(cash_withdrawal_account)
  8. 商户的提现收款账户类型(cash_withdrawal_type)
  9. 管理员/站长转账的单号(return_order_num)
  10. 管理员/站长转账的截图凭证存放路径(transfer_voucher)
  11. 提现订单状态(order_state)
  12. 聊天内容(record_content)
  13. 备注(remarks)
  14. 转账时间(passing_time)
  15. 申请时间(application_time)

商户需要提交收款二维码,并发起提现申请,系统会自动判断商户的返佣记录中的总金额与商户信息中的佣金总和是否相同,若数据不一致,则会提示站长该商户的佣金金额异常。

站长通过人工方式,扫码用户提交的收款二维码进行转账,并在后台上传转账的截图凭证。最后完成商户的提现。

该表记录商户的提现及站长的转账凭证。确保资金的安全,VipSystem Pro插件并不涉及站长和用户的真实财产。

第5项,提现验证姓名。用于站长在转账时,验证收款人是否正确,确保不会转错账。

第12项,聊天内容。其实是当商户的佣金异常时,会将系统检测的异常结果写在其中。用户可在商户中心看到异常的结果。站长则在后台提现管理中可以看到该提现订单的异常状态。

 

13. 前缀_vs_user_track:天眼系统用户行为数据存储表

该表用户存储访问网站的用户行为数据。包括机器人访问、DDOS共计、CC攻击等数据。可用于排查网站的用户访问记录,更可以用作网站防护的依据判断。

目前该表仅保留数据记录,未来会根据保存的数据做智能判断,筛选出用户画像,恶意访问等智能数据统计结果。

表字段:

  1. 唯一序号(table_id)
  2. 用户ID(user_id)
  3. 访客cookies(visitor_id)
  4. 操作类型(action_type)
  5. POST表单内容(post_content)
  6. 当前访问页面地址(current_page)
  7. 来路页面地址(parent_page)
  8. UserAgent浏览器标识(user_agent)
  9. 客户端浏览器信息(client_browser)
  10. 客户端操作系统(client_os)
  11. 客户端物理地址(client_address)
  12. 客户端IP地址(client_IP)
  13. MD5效验码(md5)
  14. 更新时间(update_time)

每一次的访问,都会生成一条记录。同一用户15分钟内不会重复创建相同内容的记录。可在配置文件中修改间隔时间及是否生成重复记录。

第5项,POST表单内容。是带有POST表单提交时,会将POST中的内容写入该字段。正常的访问如评论、发帖、登录等都包含post内容。非正常的访问,就是黑客的攻击带post请求,

比如:

  • 短时间内频繁访问wp-login.php页面,并带有POST信息,天眼系统中是看到用户名和密码的
  • 段时间内频繁访问非文章页面的。正常用户的访问页面地址基本都是文章页面,只有机器人才会

第8项,User Agent。是浏览器的信息内容,其中包含了客户端操作系统等内容,通过正则可以判断出浏览器名称及版本,以及操作系统。所以第9、10项是正则匹配第8项的结果。

第11项,客户端物理地址。可以得到用户的城市位置。是通过客户端IP获取的,需要使用“外部接口”中的“IP归属地查询”功能,否则无法得到用户的位置信息。

第13项,MD5效验,适用于比对数据是否重复。防止本来是正常用户,结果给发疯死得给死的写入重复数据。导致该表数据错误。

用户行为统计数据表包含大量信息,10万条记录大概是70MB。系统后台可以删除保留的历史记录长短及时间范围。

在未来的AI智能数据分析都会根据该表的数据作为依据。包括用户访问全站的行为流程,记录每一个用户在每一个页面的停留时间等信息。

 

千年骚狐
  • 本文由 发表于 2020年6月8日
  • 除非特殊声明,本站文章均为原创,转载请务必保留本文链接
匿名

发表评论

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: