下面继续整理成可以直接给后端开发、数据库设计和技术评审使用的《数据库 ER + 字段设计文档》。重点把 用户、会员等级、推荐关系、升级审核、商品、SKU、购物车、地址、订单、支付、积分、转账、提现、收藏、关注、浏览记录、审计日志 统一起来，同时明确主键、唯一约束、索引和状态字段。

会员推荐关系 + 新零售商城

数据库 ER + 字段设计文档

版本： V1.0
数据库建议： MySQL 8.0+
字符集： utf8mb4
排序规则建议： utf8mb4_0900_ai_ci
主键策略： BIGINT UNSIGNED / 雪花 ID 或数据库自增 ID
金额存储： BIGINT，单位“分”
积分存储： BIGINT，整数
时间： DATETIME / TIMESTAMP，建议统一 UTC 存储
软删除： 业务数据按需增加 deleted_at

1. 数据库总体设计

系统按业务域拆分：

纯文本复制数据库
│
├── 用户域
│   ├── users
│   ├── user_profiles
│   ├── user_identities
│   └── user_bank_accounts
│
├── 会员域
│   ├── member_levels
│   ├── members
│   ├── member_relations
│   ├── member_upgrade_requests
│   └── member_upgrade_logs
│
├── 商城域
│   ├── categories
│   ├── zones
│   ├── products
│   ├── product_skus
│   ├── product_images
│   ├── carts
│   └── cart_items
│
├── 交易域
│   ├── addresses
│   ├── orders
│   ├── order_items
│   ├── payments
│   └── order_logs
│
├── 资产域
│   ├── point_accounts
│   ├── point_transactions
│   ├── point_transfers
│   ├── withdrawal_requests
│   └── withdrawal_logs
│
├── 用户行为域
│   ├── favorites
│   ├── follows
│   └── browsing_histories
│
└── 系统域
    ├── announcements
    ├── service_configs
    └── audit_logs

2. ER 总体关系

核心关系：

纯文本复制                        ┌──────────────┐
                        │    users     │
                        │ 用户主表     │
                        └──────┬───────┘
                               │
             ┌─────────────────┼──────────────────┐
             │                 │                  │
             ▼                 ▼                  ▼
    ┌────────────────┐  ┌───────────────┐  ┌──────────────┐
    │ user_profiles  │  │    members    │  │ point_accounts│
    │ 用户资料       │  │ 会员          │  │ 积分账户     │
    └────────────────┘  └───────┬───────┘  └──────┬───────┘
                                 │                 │
                    ┌────────────┼───────┐         │
                    │            │       │         │
                    ▼            ▼       ▼         ▼
             member_levels   relations  upgrade  transactions
                                      requests
                    │
                    ▼
             upgrade_logs

users
  │
  ├─────────────── addresses
  │
  ├─────────────── orders
  │                    │
  │                    ├──── order_items
  │                    └──── payments
  │
  ├─────────────── carts
  │                    │
  │                    └──── cart_items
  │
  ├─────────────── favorites ───── products
  ├─────────────── follows
  └─────────────── browsing_histories ───── products

products
   │
   ├──── categories
   ├──── zones
   ├──── product_images
   └──── product_skus

point_accounts
   │
   ├──── point_transactions
   └──── point_transfers

users
   ├──── user_identities
   ├──── user_bank_accounts
   └──── withdrawal_requests

3. 核心设计原则

3.1 用户与会员分离

不要把所有会员字段全部塞进 users。

推荐：

纯文本复制users
    ↓
members
    ↓
member_levels

原因：

用户身份：

纯文本复制登录、手机号、密码、状态

会员身份：

纯文本复制会员等级、会员状态、升级

属于不同业务域。

4. users 用户主表

表名：

纯文本复制users

用途：

保存系统所有用户的基础身份。

status

纯文本复制0 = 禁用
1 = 正常
2 = 锁定

索引

纯文本复制PRIMARY KEY (id)

UNIQUE KEY uk_mobile (mobile)

KEY idx_status_created (status, created_at)

5. user_profiles 用户资料表

表名：

纯文本复制user_profiles

用途：

保存非认证型资料。

约束：

纯文本复制UNIQUE KEY uk_user (user_id)

6. user_identities 实名信息表

表名：

纯文本复制user_identities

用途：

管理实名资料。

状态：

纯文本复制0 = 未认证
1 = 审核中
2 = 已认证
3 = 认证失败

安全

身份证号不得明文存储。

推荐：

纯文本复制原始值 → 应用层加密 → 数据库存储

7. user_bank_accounts 银行账户表

表名：

纯文本复制user_bank_accounts

用途：

提现银行卡资料。

约束：

纯文本复制KEY idx_user_status (user_id, status)

银行卡号不得明文返回接口。

8. member_levels 会员等级表

表名：

纯文本复制member_levels

用途：

定义会员等级。

例如：

纯文本复制1 一星会员
2 二星会员
3 三星会员

约束：

纯文本复制UNIQUE KEY uk_code (code)
UNIQUE KEY uk_sort (sort)

9. members 会员表

表名：

纯文本复制members

用途：

记录用户当前会员身份。

约束：

纯文本复制UNIQUE KEY uk_user (user_id)
KEY idx_level (level_id)

10. member_relations 推荐关系表

表名：

纯文本复制member_relations

这是整个推荐体系的核心表。

例如：

纯文本复制A 推荐 B

记录：

纯文本复制parent_user_id = A
child_user_id = B
relation_level = 1

如果未来支持多层团队：

纯文本复制A → B → C

可以产生：

纯文本复制A → B level 1
B → C level 1
A → C level 2

约束

纯文本复制UNIQUE KEY uk_parent_child (parent_user_id, child_user_id)

KEY idx_parent_level (
    parent_user_id,
    relation_level,
    status
)

KEY idx_child (
    child_user_id
)

禁止：

纯文本复制parent_user_id = child_user_id

11. 推荐关系为什么不建议直接放 users.referrer_id

简单系统可以：

纯文本复制users.referrer_id

但本项目未来存在：

纯文本复制团队
多层级
统计
团队人数
关系查询

因此建议使用独立关系表。

如果为了查询效率，也可以在 users 增加：

纯文本复制direct_referrer_id

作为冗余字段。

但：

纯文本复制users.direct_referrer_id

和：

纯文本复制member_relations

必须由服务端事务保持一致。

12. member_upgrade_requests 升级申请表

表名：

纯文本复制member_upgrade_requests

状态：

纯文本复制pending
approved
rejected
cancelled

约束

同一个用户不能同时存在两个 pending。

实现方式：

可以通过应用层 + 唯一约束设计。

例如增加：

纯文本复制pending_flag

然后建立：

纯文本复制UNIQUE(user_id, pending_flag)

其中只有待审核状态使用固定值。

13. member_upgrade_logs 审核日志表

表名：

纯文本复制member_upgrade_logs

用途：

记录升级状态历史。

例如：

纯文本复制pending → approved

记录：

纯文本复制operator_id
from_status = pending
to_status = approved
action = approve

14. categories 商品分类表

表名：

纯文本复制categories

支持：

纯文本复制一级分类
└── 二级分类

索引：

纯文本复制KEY idx_parent_status (parent_id, status)

15. zones 商品专区表

表名：

纯文本复制zones

用途：

新品、热销、专题等运营专区。

16. zone_products 专区商品关联表

表名：

纯文本复制zone_products

因为一个商品可以属于多个专区，所以建立中间表。

约束：

纯文本复制UNIQUE(zone_id, product_id)

17. products 商品主表

表名：

纯文本复制products

状态：

纯文本复制0 = 下架
1 = 上架
2 = 草稿

18. product_skus 商品 SKU 表

表名：

纯文本复制product_skus

库存设计：

纯文本复制可售库存 = stock - locked_stock

也可以直接使用：

纯文本复制available_stock

但二者不要重复维护，避免数据不一致。

19. product_images 商品图片表

表名：

纯文本复制product_images

类型：

纯文本复制cover
gallery
detail

20. carts 购物车主表

表名：

纯文本复制carts

如果每个用户只有一个购物车，可以非常简单：

约束：

纯文本复制UNIQUE(user_id)

21. cart_items 购物车商品表

表名：

纯文本复制cart_items

约束：

纯文本复制UNIQUE(cart_id, sku_id)

加入同一 SKU 时：

纯文本复制quantity += new_quantity

而不是产生重复购物车记录。

22. addresses 收货地址表

表名：

纯文本复制addresses

索引：

纯文本复制KEY idx_user_default (user_id, is_default)

建议保证每个用户最多一个默认地址。

23. orders 订单主表

表名：

纯文本复制orders

这是商城交易核心表。

订单状态

纯文本复制pending_payment
pending_shipment
shipped
completed
cancelled
refund

可以根据实际业务增加：

纯文本复制refunding
refunded

订单号

纯文本复制UNIQUE(order_no)

24. 为什么订单必须保存快照

订单不能只存：

纯文本复制product_id

因为之后商品可能：

纯文本复制改名
改价
下架
删除
修改规格

所以订单商品必须保存：

纯文本复制商品名称
SKU 名称
价格
规格
图片

25. order_items 订单商品表

表名：

纯文本复制order_items

索引：

纯文本复制KEY idx_order (order_id)

26. payments 支付表

表名：

纯文本复制payments

状态：

纯文本复制pending
paid
failed
cancelled
refunded

约束：

纯文本复制UNIQUE(payment_no)
KEY idx_order_status(order_id, status)
UNIQUE(provider, provider_trade_no)

第三方交易号需要允许 NULL。

27. order_logs 订单状态日志

表名：

纯文本复制order_logs

operator_type：

纯文本复制user
admin
system
payment
merchant

28. point_accounts 积分账户表

表名：

纯文本复制point_accounts

约束：

纯文本复制UNIQUE(user_id)

29. point_transactions 积分流水表

表名：

纯文本复制point_transactions

这是积分系统最重要的账本表。

类型：

纯文本复制recharge
reward
transfer_in
transfer_out
order_use
withdraw
freeze
unfreeze
adjustment

约束：

纯文本复制UNIQUE(transaction_no)

建议增加：

纯文本复制UNIQUE(reference_type, reference_id, user_id, type)

但具体唯一规则需要根据业务场景调整。

30. point_transfers 积分转账记录

表名：

纯文本复制point_transfers

用于记录一次完整的 A → B 转账。

状态：

纯文本复制pending
completed
failed
cancelled

约束：

纯文本复制UNIQUE(transfer_no)

31. 积分转账数据库事务

完整转账：

纯文本复制BEGIN

锁定发送者 point_accounts
↓
锁定接收者 point_accounts
↓
检查发送方余额
↓
扣减发送方
↓
增加接收方
↓
写 sender point_transaction
↓
写 receiver point_transaction
↓
更新 point_transfer
↓
COMMIT

不能只：

纯文本复制UPDATE point_accounts

而不生成流水。

32. withdrawal_requests 提现申请表

表名：

纯文本复制withdrawal_requests

状态：

纯文本复制pending
reviewing
approved
rejected
paid
cancelled

33. 提现银行卡快照

提现不能只依赖：

纯文本复制bank_account_id

因为用户后续可能修改银行卡。

建议同时保存：

纯文本复制bank_name_snapshot
holder_name_snapshot
card_last4_snapshot

例如：

这样历史提现记录仍然能够保持当时状态。

34. withdrawal_logs 提现状态日志

表名：

纯文本复制withdrawal_logs

35. favorites 收藏表

表名：

纯文本复制favorites

约束：

纯文本复制UNIQUE(user_id, product_id)

防止重复收藏。

36. follows 关注表

表名：

纯文本复制follows

因为当前系统无法完全确认“关注”的具体业务对象，因此设计为通用结构。

例如：

纯文本复制shop
brand
product
zone

约束：

纯文本复制UNIQUE(user_id, target_type, target_id)

37. browsing_histories 浏览记录表

表名：

纯文本复制browsing_histories

约束：

纯文本复制UNIQUE(user_id, product_id)

每次浏览：

纯文本复制browse_count += 1
last_browsed_at = NOW()

不需要每次都新增一条完全重复记录。

38. announcements 公告表

表名：

纯文本复制announcements

39. audit_logs 审计日志表

表名：

纯文本复制audit_logs

整个系统的统一操作审计表。

敏感数据不要直接写进 detail_json。

40. 服务配置表

表名：

纯文本复制service_configs

例如：

纯文本复制points.exchange_rate = 100
withdraw.enabled = 1
mall.enabled = 1

敏感密钥不能放在该表以明文保存。

41. 关键 ER 关系

用户与会员

纯文本复制users 1 ───── 1 members

members N ───── 1 member_levels

推荐关系

纯文本复制users 1 ───── N member_relations
users 1 ───── N member_relations

逻辑上：

纯文本复制parent_user_id → child_user_id

升级

纯文本复制users 1 ───── N member_upgrade_requests

member_upgrade_requests
       │
       ├── from_level_id → member_levels
       ├── to_level_id   → member_levels
       └── 1 ───── N member_upgrade_logs

商品

纯文本复制categories 1 ───── N products

products 1 ───── N product_skus
products 1 ───── N product_images

zones N ───── N products
       ↓
zone_products

购物车

纯文本复制users 1 ───── 1 carts

carts 1 ───── N cart_items

cart_items N ───── 1 product_skus

订单

纯文本复制users 1 ───── N orders

orders 1 ───── N order_items

orders 1 ───── N payments

orders 1 ───── N order_logs

积分

纯文本复制users 1 ───── 1 point_accounts

point_accounts 1 ───── N point_transactions

users
 └──── N point_transfers
       ├── sender_user_id
       └── receiver_user_id

提现

纯文本复制users 1 ───── N withdrawal_requests

withdrawal_requests N ───── 1 user_bank_accounts

withdrawal_requests 1 ───── N withdrawal_logs

42. 数据库核心索引汇总

重点索引：

纯文本复制users
├── uk_mobile
└── idx_status_created

members
├── uk_user
└── idx_level

member_relations
├── uk_parent_child
├── idx_parent_level
└── idx_child

member_upgrade_requests
├── uk_request_no
├── idx_user_status
└── idx_reviewer_status

products
├── idx_category_status
├── idx_status_sort
└── idx_created

product_skus
├── uk_sku_code
└── idx_product_status

cart_items
└── uk_cart_sku

addresses
└── idx_user_default

orders
├── uk_order_no
├── idx_user_status_created
└── idx_status_created

order_items
└── idx_order

payments
├── uk_payment_no
├── idx_order_status
└── uk_provider_trade_no

point_transactions
├── uk_transaction_no
├── idx_user_created
└── idx_reference

point_transfers
├── uk_transfer_no
├── idx_sender_created
└── idx_receiver_created

withdrawal_requests
├── uk_withdrawal_no
├── idx_user_status
└── idx_status_created

favorites
└── uk_user_product

follows
└── uk_user_target

browsing_histories
└── uk_user_product

43. 外键策略

生产环境建议根据业务和数据量决定是否使用数据库 Foreign Key。

逻辑关系必须保证：

纯文本复制users.id
↓
members.user_id
↓
orders.user_id
↓
point_accounts.user_id

但对于高并发、大规模商城：

可以采用：

纯文本复制数据库索引
+
应用层完整性检查
+
事务

而不是依赖大量 FK。

无论是否使用 FK，应用层都必须验证数据归属。

44. 删除策略

核心业务数据不建议物理删除。

例如：

纯文本复制订单
支付
积分流水
提现
升级申请
审计日志

不能直接：

SQL复制DELETE

推荐：

纯文本复制status
deleted_at

或者永久保留。

45. 用户注销策略

用户注销后：

纯文本复制users.status = disabled

而不是删除整个用户。

因为用户可能仍然存在：

纯文本复制订单
积分流水
提现
推荐关系
审计记录

46. 会员升级事务

用户提交申请：

纯文本复制BEGIN

查询 members FOR UPDATE
↓
查询是否已有 pending
↓
读取当前等级
↓
读取下一等级
↓
检查业务条件
↓
INSERT member_upgrade_requests
↓
COMMIT

审核通过：

纯文本复制BEGIN

查询 upgrade_request FOR UPDATE
↓
检查 status = pending
↓
检查审核人权限
↓
检查申请人关系
↓
查询 member FOR UPDATE
↓
再次验证当前等级
↓
修改 members.level_id
↓
更新 upgrade_request
↓
INSERT member_upgrade_logs
↓
INSERT audit_logs
↓
COMMIT

47. 订单创建事务

纯文本复制BEGIN

锁定 SKU
↓
检查商品状态
↓
检查库存
↓
重新计算商品价格
↓
重新计算优惠
↓
重新计算积分
↓
重新计算运费
↓
创建订单
↓
创建 order_items
↓
锁定库存
↓
清理购物车
↓
写 order_logs
↓
COMMIT

注意：

不能以浏览器提交的总金额作为订单金额依据。

48. 订单支付完成事务

支付回调：

纯文本复制BEGIN

验证第三方签名
↓
查询 payments FOR UPDATE
↓
幂等检查
↓
核对订单
↓
核对支付金额
↓
更新 payment
↓
更新 order
↓
记录 order_logs
↓
COMMIT

49. 积分抵扣规则

现有系统页面显示：

纯文本复制100 积分 = 1 元

建议数据库配置：

纯文本复制points_to_cent = 100

例如：

纯文本复制100积分 → 100分人民币
500积分 → 500分人民币

但最终允许抵扣多少，还需要配置：

纯文本复制订单商品
最大抵扣比例
商品是否允许积分抵扣
用户当前积分

因此建议商品或系统配置增加：

纯文本复制points_discount_enabled
points_discount_rate

50. 积分与订单的关系

订单应保存：

纯文本复制used_points
points_discount_cent

例如：

纯文本复制商品金额：10000分
使用积分：500
积分抵扣：500分
实际支付：9500分

同时生成：

纯文本复制point_transactions
type = order_use
reference_type = order
reference_id = order_id

51. 提现业务模型

如果业务规则确实是：

纯文本复制积分 → 可提现

那么建议不要简单把积分余额直接改成“钱”。

明确划分：

纯文本复制point_accounts
    ↓
积分
    ↓
提现申请
    ↓
withdrawal_requests
    ↓
财务处理

这样可以避免：

纯文本复制购物抵扣积分
转账积分
可提现积分

三个概念混为一谈。

如果实际上存在“现金余额”和“积分余额”两种资产，则应进一步拆成：

纯文本复制asset_accounts
asset_transactions

不要继续共用一个 point_accounts。

52. 会员等级数据口径

目前前端检查发现：

纯文本复制会员平台：一星会员

商城个人中心：普通会员

数据库设计上必须避免两套等级字段。

错误：

纯文本复制users.member_level = 1
mall_users.level = normal
members.level_id = 1

推荐：

纯文本复制members.level_id

作为唯一会员等级来源。

商城只读取：

纯文本复制members.level_id

通过服务层统一转换为展示名称。

53. 推荐关系数据口径

同样不要出现：

纯文本复制users.referrer_id
team.parent_id
member.parent_id

多个地方分别保存一份关系。

推荐关系唯一来源：

纯文本复制member_relations

如有缓存字段：

纯文本复制users.direct_referrer_id

只能作为冗余查询字段。

54. 商城商品数据口径

价格唯一来源：

纯文本复制product_skus.price_cent

订单创建后：

纯文本复制order_items.price_cent

作为历史成交价格快照。

即：

纯文本复制实时商品价格
      ↓
product_skus

历史订单价格
      ↓
order_items

不能反过来读取当前商品价格显示历史订单。

55. 订单状态机

纯文本复制                 ┌───────────────┐
                 │ pending_payment│
                 └───────┬───────┘
                         │ 支付
                         ▼
                 ┌───────────────┐
                 │pending_shipment│
                 └───────┬───────┘
                         │ 发货
                         ▼
                    ┌─────────┐
                    │ shipped │
                    └────┬────┘
                         │ 收货
                         ▼
                    ┌─────────┐
                    │completed│
                    └─────────┘

pending_payment
       │
       └──── 取消 → cancelled

非法状态转换必须拒绝。

56. 会员升级状态机

纯文本复制pending
   │
   ├── approve → approved
   │
   └── reject  → rejected

要求：

纯文本复制approved → 不允许再次审核
rejected → 不允许再次审核

57. 提现状态机

纯文本复制pending
   ↓
reviewing
   ├── rejected
   │
   └── approved
          ↓
         paid

状态不能由客户端直接指定。

错误：

json复制{
  "status": "paid"
}

正确：

纯文本复制提交申请 → pending
审核 → approved
财务打款 → paid

58. 数据库事务隔离

涉及：

纯文本复制订单库存
积分
提现
会员升级

建议至少考虑：

纯文本复制REPEATABLE READ

并结合：

纯文本复制SELECT ... FOR UPDATE

或乐观锁：

纯文本复制version

具体选型由并发量和现有架构决定。

59. 并发控制

积分

使用：

纯文本复制行锁
或
version 乐观锁

库存

使用：

纯文本复制available_stock

更新：

纯文本复制UPDATE product_skus
SET stock = stock - ?
WHERE id = ?
  AND stock >= ?

通过受影响行数判断库存是否足够。

重复订单提交

使用：

纯文本复制Idempotency-Key

60. 敏感字段存储原则

以下字段建议应用层加密：

纯文本复制身份证号
银行卡号

以下字段数据库中可直接保存，但接口需要脱敏：

纯文本复制手机号
微信号
姓名

数据库日志不能出现：

纯文本复制password
token
完整身份证
完整银行卡

61. 数据备份

至少包含：

纯文本复制users
members
member_relations
member_upgrade_requests
products
product_skus
orders
order_items
payments
point_accounts
point_transactions
point_transfers
withdrawal_requests
audit_logs

重点业务表需要：

纯文本复制每日备份
增量备份
异地备份
恢复演练

62. 推荐数据库分库边界

V1 不建议一开始就物理分库。

推荐逻辑分域：

纯文本复制user
member
mall
order
asset
system

数据库仍可以先：

纯文本复制一个 MySQL

通过表前缀/代码模块区分：

纯文本复制users
members
products
orders
point_accounts

后期数据量上升再考虑：

纯文本复制读写分离
分库
分表
缓存
消息队列

63. 推荐缓存

可以缓存：

纯文本复制member_levels
categories
zones
product detail
service_configs
announcements

不建议直接缓存作为最终数据源：

纯文本复制积分余额
订单状态
提现状态
会员等级
支付状态

这些必须最终以数据库为准。

64. 推荐 Redis 数据

例如：

纯文本复制session:{user_id}

login:fail:{mobile}

rate_limit:login:{ip}

product:{id}

category:list

member:level:{id}

积分余额如果做缓存，必须有严谨的一致性方案，不建议 V1 直接引入复杂缓存账本。

65. 数据字典

用户状态

纯文本复制0 disabled
1 active
2 locked

会员状态

纯文本复制0 disabled
1 active

升级状态

纯文本复制pending
approved
rejected
cancelled

商品状态

纯文本复制draft
on_sale
off_sale

订单状态

纯文本复制pending_payment
pending_shipment
shipped
completed
cancelled
refund

支付状态

纯文本复制pending
paid
failed
cancelled
refunded

提现状态

纯文本复制pending
reviewing
approved
rejected
paid
cancelled

66. 推荐数据库命名规范

表名：

纯文本复制snake_case

例如：

纯文本复制member_upgrade_requests

主键：

纯文本复制id

外键：

纯文本复制user_id
product_id
order_id

时间：

纯文本复制created_at
updated_at

状态：

纯文本复制status

金额：

纯文本复制xxx_amount_cent

数量：

纯文本复制quantity

积分：

纯文本复制points

67. 不建议的数据设计

不建议 1：订单直接保存商品名称 ID

错误：

纯文本复制orders.product_id

因为一个订单可能包含多个商品。

应该：

纯文本复制orders
    ↓
order_items

不建议 2：积分只保存一个余额

错误：

纯文本复制users.points

推荐：

纯文本复制point_accounts
point_transactions

不建议 3：提现直接修改积分

必须产生：

纯文本复制withdrawal_request
+
point_transaction

并且考虑冻结。

不建议 4：会员等级存在多个表

只允许：

纯文本复制members.level_id

作为权威数据。

不建议 5：前端传价格直接入库

错误：

json复制{
  "price": 99,
  "total": 198
}

服务端必须自己计算。

68. 推荐完整 ER 图

纯文本复制users
│
├── 1:1 ── user_profiles
├── 1:1 ── user_identities
├── 1:N ── user_bank_accounts
├── 1:1 ── members
│           │
│           └── N:1 ── member_levels
│
├── 1:N ── member_relations
│           ├── parent_user_id
│           └── child_user_id
│
├── 1:N ── member_upgrade_requests
│           │
│           ├── from_level_id
│           ├── to_level_id
│           └── 1:N member_upgrade_logs
│
├── 1:1 ── carts
│           └── 1:N cart_items
│
├── 1:N ── addresses
│
├── 1:N ── orders
│           ├── 1:N order_items
│           ├── 1:N payments
│           └── 1:N order_logs
│
├── 1:1 ── point_accounts
│           └── 1:N point_transactions
│
├── 1:N ── point_transfers
│
├── 1:N ── withdrawal_requests
│           └── 1:N withdrawal_logs
│
├── 1:N ── favorites ── N:1 products
├── 1:N ── follows
└── 1:N ── browsing_histories ── N:1 products

categories
└── 1:N products
          ├── 1:N product_skus
          ├── 1:N product_images
          └── N:N zones
                  │
                  └── zone_products

69. V1 核心表清单

第一阶段数据库至少建立：

纯文本复制users
user_profiles
members
member_levels
member_relations

member_upgrade_requests
member_upgrade_logs

categories
products
product_skus

carts
cart_items

addresses

orders
order_items
payments
order_logs

point_accounts
point_transactions
point_transfers

withdrawal_requests
withdrawal_logs

user_identities
user_bank_accounts

favorites
follows
browsing_histories

audit_logs
announcements

70. 数据库开发优先级

P0：身份与会员

纯文本复制users
user_profiles
members
member_levels
member_relations
member_upgrade_requests
member_upgrade_logs

P1：商城交易

纯文本复制categories
products
product_skus
carts
cart_items
addresses
orders
order_items
payments
order_logs

P1：资产

纯文本复制point_accounts
point_transactions
point_transfers
withdrawal_requests
withdrawal_logs

P2：账户扩展

纯文本复制user_identities
user_bank_accounts
favorites
follows
browsing_histories

P2：系统

纯文本复制announcements
audit_logs
service_configs

71. 第一阶段数据库必须重点测试

用户

纯文本复制重复手机号
禁用用户
软删除用户
登录 Session

推荐

纯文本复制自己推荐自己
重复推荐
循环推荐
不存在推荐人
禁用推荐人

会员升级

纯文本复制跨级升级
重复申请
重复审核
越权审核
并发审核
审核后再次操作

商品

纯文本复制库存不足
SKU 下架
商品下架
SKU 并发扣库存

订单

纯文本复制重复创建
价格改变
库存改变
支付重复回调
订单越权
订单状态非法转换

积分

纯文本复制余额不足
重复转账
并发转账
负数积分
自己转给自己

提现

纯文本复制资料不完整
余额不足
重复提交
重复审核
并发提现
修改银行卡后的历史提现

72. 最终数据库架构原则

系统最终必须保持以下几个“唯一数据源”：

纯文本复制用户身份
→ users

会员等级
→ members.level_id

会员等级定义
→ member_levels

推荐关系
→ member_relations

商品实时价格
→ product_skus.price_cent

订单历史价格
→ order_items.price_cent

订单状态
→ orders.status

支付状态
→ payments.status

积分余额
→ point_accounts

积分历史
→ point_transactions

提现状态
→ withdrawal_requests

系统操作记录
→ audit_logs

避免同一事实在多个表中独立维护。

73. 数据一致性优先级

数据一致性优先于页面显示。

例如：

纯文本复制前端显示余额 = 1000
数据库余额 = 800

最终必须以数据库账本为准。

同样：

纯文本复制前端显示订单已支付
数据库订单未支付

应以支付回调验证后的服务端状态为准。

74. 推荐后续开发文档链路

数据库设计完成后，建议形成完整的技术文档链：

纯文本复制01 产品需求文档
        ↓
02 页面 / 原型文档
        ↓
03 API 接口文档
        ↓
04 数据库 ER + 字段设计
        ↓
05 权限设计
        ↓
06 状态机设计
        ↓
07 测试用例
        ↓
08 部署 / 运维文档

最终前后端开发人员可以按照：

纯文本复制页面
 ↓
API
 ↓
Service
 ↓
数据库

一条链路进行开发。

75. V1 数据库最终推荐架构

纯文本复制                  ┌───────────────┐
                  │     users     │
                  └───────┬───────┘
                          │
         ┌────────────────┼─────────────────┐
         │                │                 │
         ▼                ▼                 ▼
     会员域             商城域            资产域
         │                │                 │
   ┌─────┼─────┐     ┌────┼─────┐      ┌────┼─────┐
   │     │     │     │    │     │      │    │     │
 levels members relation products cart order points withdraw
   │              │       │       │      │    │     │
   │              │       SKU     │      │    │     │
   │              │               │      │    │     │
 upgrade          │              items   │ transaction
 request/logs     │                      │ transfer
                  │                      │
                team                    payment
                                         │
                                       logs

                         ┌───────────────┐
                         │    system     │
                         ├───────────────┤
                         │ announcements │
                         │ audit_logs    │
                         │ config        │
                         └───────────────┘

这套结构能够覆盖当前已检查出的会员推荐、等级升级、审核、团队、商城、订单、积分、转账、提现和用户资料功能，同时给后续后台管理、商家体系、多层团队和财务审核预留扩展空间。

现在三份文档已经形成一条完整开发链：

① 页面/原型 → ② API → ③ 数据库 ER/字段。

下一步最有价值的是把这三份继续整合成一份 《完整软件开发需求规格书 PRD》，然后再往下拆成 前端任务清单、后端任务清单、数据库建表 SQL、测试用例，开发团队就可以直接按 Sprint 开始执行。