你要的 creator 层
已经建好了,而且填满了。

我去线上把 schema 全查了一遍。「一个 creator 多个社媒、各自带粉丝和中播指标」这件事, 平台库里已经有 445 万行数据在跑。 真正的问题是—— 没有任何一张 coordinator_* 表外键到它。 达人身份恰好在 scouting 交接进 coordinator 的那一刻被丢掉了。

我把这份 schema 和你的提案交给了一个独立评审(只给结构和数字,不给我的结论)。 它的第一句话是:「这大约 20% 是新模型,80% 是接线。」本文按这个判断组织。

现有库里的实际分布,新表一律按此:

我原来打算在联系方式上加一个 ownership 列。评审直接否掉了,理由很硬:

我接受。差别在于:mgmt@tiddle.io 这个邮箱是 tiddle 的, 不是 laura 的;它在 2026-03 到 2026-08 期间被用来联系 laura。 laura 换经纪之后,这条历史必须还在——否则去年那笔合作是谁在谈就查不出来了。

所以拆成两张表:方法归谁 和 方法用于谁。

-- ① 联系方式本身,归属于它真正的主人
create table contact_methods (
  id                uuid primary key default gen_random_uuid(),
  contact_id        uuid not null references contacts(id),   -- 经纪邮箱 → 指向经纪 contact
  method_type       text not null check (method_type in
                      ('email','phone','whatsapp','wechat','telegram','other')),
  raw_value         text not null,
  normalized_value  text not null,
  label             text,
  verification_status text not null default 'unverified',
  mergeable         boolean not null default true,   -- ← agency / 共享信箱设 false
  valid_during      tstzrange not null default tstzrange(now(), null, '[)'),
  created_at        timestamptz not null default now(),
  unique (contact_id, method_type, normalized_value),
  unique (id, contact_id)                                    -- 供下表复合外键引用
);

-- ② 这个方法「被用于」哪个达人 —— agency / personal 标在这里
create table contact_method_assignments (
  id                       uuid primary key default gen_random_uuid(),
  creator_contact_id       uuid not null references contacts(id),  -- 用于谁
  contact_method_id        uuid not null,
  method_owner_contact_id  uuid not null,                          -- 方法归谁
  assignment_type          text not null check (assignment_type in ('personal','agency')),
  source_relationship_id   uuid,                                   -- agency 时必须指向那条经纪关系
  valid_during             tstzrange not null default tstzrange(now(), null, '[)'),
  is_primary               boolean not null default false,

  foreign key (contact_method_id, method_owner_contact_id)
    references contact_methods(id, contact_id),

  check (
    (assignment_type='personal' and method_owner_contact_id = creator_contact_id
       and source_relationship_id is null)
    or
    (assignment_type='agency'   and method_owner_contact_id <> creator_contact_id
       and source_relationship_id is not null)
  )
);

这样白送三件事:

• 一个经纪邮箱可以同时指派给它旗下多个达人,不需要复制
• 达人换经纪时,结束旧 assignment 的 valid_during 即可,历史路由信息完整保留
• mergeable=false 直接解决身份合并炸裂——那个名下 8,725 条会话的 slogansocial.com 不再是合并键

contacts.emails / contacts.phone 这两个 text[] 在迁移期保留为只读投影,不立刻删。

-- 一次合作
create table coordinator_collaborations (
  id                uuid primary key default gen_random_uuid(),
  campaign_id       int  not null references campaigns(id),
  lifecycle_status  text not null,
  phase             text not null,
  renewal_of_collaboration_id uuid references coordinator_collaborations(id),
  renewal_round     int  not null default 0 check (renewal_round >= 0),
  agreed_at         timestamptz,
  closed_at         timestamptz,
  legacy_engagement_id uuid unique,        -- 迁移期回指,永不复用
  created_at        timestamptz not null default now(),
  check (renewal_of_collaboration_id is null or renewal_round > 0)
);

-- 参与这次合作的达人(多对多 —— 打包合作靠这张表)
create table coordinator_collaboration_creators (
  id                 uuid primary key default gen_random_uuid(),
  collaboration_id   uuid not null references coordinator_collaborations(id),
  creator_contact_id uuid not null references contacts(id),
  unique (collaboration_id, creator_contact_id),
  unique (id, collaboration_id, creator_contact_id)
);

-- 这次合作里谁在代表谁谈 —— 快照,不靠事后推断当前经纪关系
create table coordinator_collaboration_representatives (
  id               uuid primary key default gen_random_uuid(),
  collaboration_id uuid not null references coordinator_collaborations(id),
  agency_contact_id uuid not null references contacts(id),
  represented_creator_contact_id uuid references contacts(id),  -- null = 代表整个打包
  negotiation_role text not null default 'negotiator'
    check (negotiation_role in ('negotiator','contracting_party','payment_recipient')),
  unique (collaboration_id, agency_contact_id,
          coalesce(represented_creator_contact_id,'00000000-0000-0000-0000-000000000000'::uuid),
          negotiation_role)
);

交付物挂到稳定的账号,不挂 handle 字符串

create table coordinator_collaboration_deliverables (
  id                  uuid primary key default gen_random_uuid(),
  collaboration_id    uuid not null references coordinator_collaborations(id),
  collaboration_creator_id uuid not null,
  creator_contact_id  uuid not null,
  creator_profile_id  uuid,          -- ← 具体发在哪个社媒账号上;签约后才定也允许 null
  sequence            int  not null check (sequence > 0),
  deliverable_type    text not null,
  status              text not null,
  due_at              timestamptz,

  foreign key (collaboration_creator_id, collaboration_id, creator_contact_id)
    references coordinator_collaboration_creators(id, collaboration_id, creator_contact_id),
  -- 保证这个账号确实属于这个达人,不会张冠李戴
  foreign key (creator_profile_id, creator_contact_id)
    references creator_profiles(id, creator_id),
  unique (collaboration_id, sequence)
);

-- 返工 / 改片 / 补拍
create table coordinator_deliverable_attempts (
  id              uuid primary key default gen_random_uuid(),
  deliverable_id  uuid not null references coordinator_collaboration_deliverables(id),
  attempt_number  int not null check (attempt_number > 0),
  reason          text,
  status          text not null,
  submitted_at    timestamptz, approved_at timestamptz,
  unique (deliverable_id, attempt_number)
);

-- 发布的成片 ←→ 已有的内容指标表,白送播放数据
create table coordinator_deliverable_social_contents (
  deliverable_id    uuid not null references coordinator_collaboration_deliverables(id),
  social_content_id uuid not null references social_contents(id),
  primary key (deliverable_id, social_content_id)
);

最后那张表值得注意:接上之后,「这条片子发出去播了多少」不需要新建任何采集链路—— social_content_metrics 已经在采了。

打包报价 ≠ 实付

这直接对应我上一版指出的空洞:4,740 条交付物里只有 16 条填了实付金额(0.3%)。 根因是「谈成多少」和「实付多少」被挤在同一个字段上。拆开:

-- 谈成的对价 —— 支持打包价、单条价、以物易物、纯佣金
create table coordinator_collaboration_considerations (
  id                 uuid primary key default gen_random_uuid(),
  collaboration_id   uuid not null references coordinator_collaborations(id),
  consideration_type text not null check (consideration_type in
    ('cash_package','cash_fee','barter','gift','commission','other')),
  amount             numeric(19,4),
  currency           char(3),
  description        text,
  estimated_value    numeric(19,4),        -- 以物易物时的折算价值
  estimated_value_currency char(3),
  check ((amount is null and currency is null)
      or (amount >= 0 and currency ~ '^[A-Z]{3}$'))
);
-- 一次合作最多一个打包价
create unique index coordinator_one_cash_package
  on coordinator_collaboration_considerations(collaboration_id)
  where consideration_type = 'cash_package';

-- 实际打款 —— 独立账本,可分期、可退款、指回当初谈成的那条
create table coordinator_collaboration_payments (
  id                uuid primary key default gen_random_uuid(),
  collaboration_id  uuid not null references coordinator_collaborations(id),
  deliverable_id    uuid references coordinator_collaboration_deliverables(id),
  consideration_id  uuid references coordinator_collaboration_considerations(id),
  payee_contact_id  uuid not null references contacts(id),   -- 可能是经纪公司
  amount            numeric(19,4) not null,
  currency          char(3) not null,
  direction         text not null default 'outbound'
    check (direction in ('outbound','refund','chargeback')),
  source_kind       text not null,       -- finance_webhook | operator | contract
  source_ref        text not null,       -- 打款回执 / 操作人 / 合同编号
  paid_at           timestamptz not null
);

合同做成版本化 + 多对多

因为存在一份总合同覆盖多次合作的情况,合同不能是 collaboration 的子表。

create table coordinator_contracts (
  id uuid primary key default gen_random_uuid(),
  status text not null check (status in ('draft','sent','partially_signed','signed','voided'))
);
create table coordinator_contract_versions (
  id uuid primary key default gen_random_uuid(),
  contract_id uuid not null references coordinator_contracts(id),
  version int not null check (version > 0),
  document_uri text not null, content_sha256 text,
  unique (contract_id, version)
);
create table coordinator_contract_collaborations (
  contract_id uuid not null references coordinator_contracts(id),
  collaboration_id uuid not null references coordinator_collaborations(id),
  primary key (contract_id, collaboration_id)
);

今天的约束是 unique (reference_id) where lifecycle_status='active' (coord_eng_active_ref_uq)。评审指出了它的后果:

这不是理论问题:续约刻意复用同一个 reference_id 并把上一轮归档,正是为了满足这条索引。所以「上一轮的晚到邮件飘到新一轮」今天是可以发生的。 改成永久别名表:

create table coordinator_collaboration_external_references (
  id               uuid primary key default gen_random_uuid(),
  collaboration_id uuid not null references coordinator_collaborations(id),
  external_system  text not null,        -- 'scheduler'
  external_account text not null,        -- 上游租户,防止跨租户撞号
  reference_id     text not null,
  created_at       timestamptz not null default now(),
  unique (external_system, external_account, reference_id)   -- 永久唯一,不看状态
);

上面的 DDL 解决了身份、打包、多平台、返工、非现金对价。但下面这些还不够:

前 9 行是这次要做的;后 5 行我建议明确留白,不要为了「看起来完备」现在就建—— 使用权和税费模型都值得独立设计。

拿 51,455 条现有 engagement 按 (handle, platform) 去撞 creator_profiles:

你的定义是:Engagement = 达人本身,名下挂多次 collaboration。评审明确反对沿用这个词:

我认为可以两全,而且这是我的建议:

等旧表退役之后,要不要改名成 coordinator_engagements 再说—— 那时改名是纯粹的重命名,没有语义歧义。

1. 表名分歧怎么定? 我建议界面叫 Engagement、库里叫 coordinator_creator_relationships(§08)。如果你坚持库里也叫 engagement,那必须先把旧表改名腾出这个词,迁移风险会明显上升。
2. contact_socials 和 creator_profiles 重叠 208 万行,谁退役? 我建议保 creator_profiles(scouting 在用、带指标),contact_socials 降为只读兼容视图。但要确认没有别的服务在写它。
3. organizations 表是空的(0 行)。 评审建议给关系加一个 principal/租户维度。如果短期内只有一个主体(JellyOtter),我倾向先不加,避免过度设计——你确认一下有没有多主体计划。
4. 使用权 / 独家期 / 税费抽成 要不要这次一起做? 我建议留白,单独设计。但如果合同里已经在谈独家期,那它其实已经是刚需了。

schema 与规模数据取自生产库直查(2026-07-26)。
独立评审:GPT-5.6(codex, reasoning=high),仅提供结构与数字、不提供结论。
前序文档:01 架构 · 02 CRM 拆分 · 03 Campaign 统一 · 04 身份翻转