核心数据库架构设计

本设计严格遵循 “以品牌为锚点” 的协作模型，并重点解决 达人私有数据隔离、动态保护期计算 以及 跨商家协作 的数据结构需求。

1. 实体关系图 (ER Diagram)

2. 详细表结构设计说明

2.1 租户与策略配置

• merchants (商家)
  • 基础租户表。
• merchant_configs (商家策略配置)
  • 对应文件 3 中的“保护期配置”
  • merchant_id (PK)
  • protection_days_contact: 默认为 15 天。
  • protection_days_sampling: 默认为 35 天。
  • protection_days_fulfilled: 默认为 35 天。
  • max_samples_per_creator: 限制单个达人最大同时寄样数。

2.2 资产管理 (Assets)

• brands (品牌)

  • 系统的核心逻辑锚点。
  • id: 唯一标识。
  • merchant_id: 归属商家。
  • code: 品牌代码 (用于ERP对接)。

• products (产品/SKU)

  • id: 内部ID。
  • brand_id: 归属品牌。
  • sku: 商家SKU编码。
  • product_img: 图片URL。

2.3 达人数据公私分离 (Creator Isolation)

这是系统最关键的数据安全设计，参考文件跨商家品牌合作 的隔离规则。

• creators_public (公域档案)

  • 数据来源：TikTok Open API。
  • 可见性：全系统所有租户共享（单例模式）。
  • tiktok_open_id: 唯一索引。
  • handle: @username。
  • follower_count: 粉丝数。
  • region: 国家/地区。

• creators_private (私域档案)

  • 数据来源：BD 手工录入。
  • 可见性：严格行级隔离 (Row Level Security)。只有 merchant_id 匹配时可见。
  • creator_public_id: 关联公域ID。
  • merchant_id: 数据所有者（包括通过合作获得权限的乙方，填写的也是归属于乙方的数据）。
  • email: 私密邮箱。
  • whatsapp: 私密电话。
  • internal_memo: 内部备注。
  • 联合唯一索引：(merchant_id, creator_public_id)。

2.4 合作关系核心表 (Cooperation Logic)

对应文件概念模型，管理 “BD - 品牌 - 达人” 的铁三角关系。

• cooperations
  • id (PK)
  • brand_id (FK): 逻辑锚点。即使是跨商家合作，此处也指向甲方的 Brand ID。
  • creator_public_id (FK): 达人。
  • bd_user_id (FK): 当前负责的 BD。
  • status (Int):
    • 1 (MANAGED): 占用中，私有。
    • 0 (POOL): 公海，无主。
  • 生命周期字段 (对应达人运营体系):
    • protection_stage: 枚举 (CONTACT, SAMPLING, FULFILLED)。
    • last_action_time: 每次交互（建联、发货、回填视频）时更新。
    • release_deadline: 计算字段。last_action_time + merchant_configs 中对应的天数。
  • 核心约束：
    • 唯一索引 (brand_id, creator_public_id) WHERE status = 1。
    • 解释：确保同一品牌下，同一时间只有一个 BD 能拥有该达人。

2.5 跨商家授权 (Collaboration)

• brand_collaborations
  • id (PK)
  • brand_id (FK): 被授权的甲方品牌。
  • owner_merchant_id (FK): 甲方。
  • partner_merchant_id (FK): 乙方。
  • status: ACTIVE, PAUSED.
  • 作用：当乙方 BD 登录时，系统查询此表，将其有权的“外部品牌”混入品牌选择列表中。

2.6 履约与业绩 (Fulfillment)

• sample_orders (寄样单)

  • cooperation_id: 关联合作。
  • store_id: 发货的 TikTok 店铺。
  • shipping_address_snapshot (JSON): 地址快照。防止达人修改地址后影响历史订单记录。
  • logistics_status: TO_SHIP, SHIPPED, DELIVERED.

• sample_order_items (寄样明细)

  • sample_order_id: 父订单。
  • product_id: 关联的具体 SKU。
  • quantity: 数量。

• video_performances (业绩归因)

  • cooperation_id: 关键归因字段。即便是跨商家合作，也通过此字段找到负责的 BD 和合作关系。
  • tiktok_video_id: 平台视频ID。
  • gmv_amount: 销售额。
  • is_settled: 是否已结算佣金（用于财务对账）。

3. 关键业务逻辑 SQL 映射

3.1 检查是否可认领 (Check Availablity)

-- 场景：BD 想要认领达人 Tony (id=101) 为 Brand X (id=5) 推广
-- 逻辑：检查该品牌下是否已有由其他人负责的活跃合作
SELECT count(*) 
FROM cooperations 
WHERE brand_id = 5 
  AND creator_public_id = 101 
  AND status = 1; -- 1=MANAGED
-- 结果为 0 则允许认领

3.2 每日公海释放 (Daily Release Job)

-- 场景：系统每日定时任务，释放超时达人
UPDATE cooperations
SET 
    status = 0, -- 转为公海 POOL
    bd_user_id = NULL
WHERE 
    status = 1 
    AND release_deadline < NOW(); -- 当前时间超过了截止时间

3.3 跨商家数据隔离查询

-- 场景：查询达人详情（包括私密信息）
-- 假设当前登录者是 Merchant B 的 BD (ID=200)
SELECT 
    pub.handle,
    pub.follower_count,
    priv.email,       -- 只有属于 Merchant B 的记录才会被查出
    priv.whatsapp
FROM creators_public pub
LEFT JOIN creators_private priv 
    ON pub.id = priv.creator_public_id 
    AND priv.merchant_id = (SELECT merchant_id FROM users WHERE id = 200) -- 关键隔离条件
WHERE pub.id = 101;