#DynamoDB 表关系图

• 2026-04-26: 9 个 CDK stack deployed(StorageStack / SqsStack / IamStack / LambdaStack / CognitoStack / ContactsStack / MonitoringStack / EventBridgeStack / MessageSystemStack + 条件性 GitHubOidcStack)
• 2026-04-23: deep audit(AWS CLI 实查 + CDK 代码交叉验证)
• 2026-03-02: 上次全量 audit
• call-analysis / call-events / LeadTracking-v2 仍是 DDB-primary;calls / messages / leads 已切换到 Neon-primary read(DDB 表保留作 backward-compat)

ProjectionType: ALL）

call-events 有 2 个 GSI：transcriptionJobName-index 和 sessionId-index（RC session 关联）。

⚠ 所有 11 个 GSI 均 ALL projection，写入成本 12 倍。其中 3 个 GSI 记录数为 0，建议排查后删除或改为 KEYS_ONLY。TODO：2026-03-02 审计未记录具体是哪 3 个 GSI。候选（按 feature status 推断，未 verify）：call_outcome.outcome_category-callStartTime-index / call_categorization.follow_up_type-callStartTime-index / staff_performance...name-callStartTime-index。下次 audit 需 per-GSI scan --projection-expression 确认。

• 无 Deletion Protection、无 PITR、全部 removalPolicy: DESTROY — test 环境允许随时重建
• BlackoutPeriods / OperatingHours 同时存在 orangetheory-* 和 studio-* 两个版本。Prod 已清理仅保留 studio-*，test 的 orangetheory-* 版本应在下次部署时清理。⚠️ 2026-04-23 live 发现：orangetheory-BlackoutPeriods-test 有 29 items（2026-01-10 创建），studio-BlackoutPeriods-test 只有 1 item——legacy 表的数据量反而更多。下次部署清理前必须先把 29 items 迁移到 studio-*，否则丢数据。
• 缺少: LeadTracking（CDK 未部署到 test）、ConnectionService（孤儿表，从未创建）、Legacy 4 张（Pre-CDK 手动创建）

#:::

#实体关系

#全局关系图

完整的 DynamoDB 全量表关系图（21 张表 · 36 GSIs · 色彩分组 + 关系箭头），源文件: diagrams/dynamodb.drawio

#数据隔离模型

storeId 是数据围墙 — 每个门店只能看到自己电话号码关联的数据：

老板 (userId)
  ├── 门店 A (storeId-A)
  │     ├── +1914265xxxx ──→ 门店 A 的 SMS / 通话 / 线索
  │     └── +1914265xxxx ──→ 门店 A 的 SMS / 通话 / 线索
  │
  └── 门店 B (storeId-B)
        ├── +1978489xxxx ──→ 门店 B 的 SMS / 通话 / 线索
        └── +1978489xxxx ──→ 门店 B 的 SMS / 通话 / 线索

❌ 门店 A 看不到门店 B 的数据
❌ 同一个客户在两家店 = 两条独立记录
✅ 老板可以切换门店分别查看

#Phone Management 数据流

核心问题：哪个电话号码属于哪个门店？

#注意事项

::: danger siteId ≠ storeId — 两个完全不同的字段！

• call-analysis.siteId = providerAccountId（numeric，RingCentral 账号 ID，如 277275028）
• StoresV2.storeId = UUID（如 18a16bde-8f20-4442-9b95-35f9d144b0e7）
• 两者不可互换！ 要从通话记录关联到门店：phoneNumber → PhoneStoreAssignments → storeId
• call-analysis.clientId = franchise-providerAccountId（如 orangeTheory-277275028）
• call-analysis.franchise = 品牌名（如 orangeTheory）—— GSI franchise-callStartTime-index / franchise-siteId-index 用此字段

::: ::: info ⚠️ siteId / providerAccountId 即将 rename → accountId siteId 已统一 rename 为 account_id(callytics-common 0.22.0,migration 0016,2026-04-25 完成)。GSI 索引名 franchise-siteId-index 等不会变(DDB 索引名不能改名),但 item 内字段名已切换。详见 identity-fields.md §1.3 + docs/archive/identity-naming-history.md 演变史。

::: 表名前缀

PhoneNumbers 表的 extensionId 字段类型不一致：有分机的号码为 Number 类型，无分机的为空 String。代码需兼容两种类型。

#Archive 候选清单 { #archive }

审计日期: 2026-04-23 · AWS CLI 实查 + CDK 代码引用 + 全仓库 grep 交叉验证 2026-03-02 首次 audit；2026-04-23 deep re-audit 发现 RCU 数据与前次结论的 drift（见各节 live 提示）。

#🔴 DEAD — archive 前必须 CloudTrail 追踪读源

::: warning 2026-04-23 live 发现：DEAD 表并非完全零读 aws cloudwatch get-metric-statistics --metric-name ConsumedReadCapacityUnits --period 604800 显示所有 4 张 DEAD 表在过去 7 天都有 2-16 RCU 的读取。读量极低，但 "零业务读写" 的旧结论已被证伪。archive 前必须用 CloudTrail 定位读源，否则冒 "删掉仍在 low-volume 被读的表" 风险。

另：client-configurations 经 aws lambda get-function-configuration RingCentralTokenRefresher-Multi-Tenant 验证，运行时 env var CLIENT_CONFIG_TABLE_V1=client-configurations 被设置（而非 doc 之前推断的空串）——这是 legacy Python Lambda，属于 ConnectionService-CallAnalysisConfigurations-prod 的同批退役范围。