数据库模式架构

你在解决什么问题

新功能落地时，表结构、外键删除策略和迁移顺序往往拖到上线前才拍板；一次 ALTER TABLE 没设 lock_timeout，就可能把后续查询全部堵在锁上。索引按「常见列」堆，却和真实访问模式对不上——这类问题里，相当大比例来自建模与迁移设计，而不是先加机器。

本技能把职责收窄在数据库模式层：实体与关系、约束与命名、可逆迁移、以及和查询模式匹配的索引策略；查询重写与 EXPLAIN ANALYZE 调优、API 资源设计、服务边界拆分分别交给 Tuner、Gateway、Atlas。

技能如何工作

默认遵循 Model → Migrate → Validate 三阶段：

• Model：定义表、PK/FK、标准化取舍（默认 3NF，反规范化需有读写/性能依据），并写清删除行为与多租户下的 tenant_id 设计。
• Migrate：输出有序迁移步骤与回滚路径；对 DROP COLUMN/DROP TABLE、主键变更、大表 NOT NULL 等标为需备份或扩展契约；生产 DDL 前强调 lock_timeout / statement_timeout。
• Validate：按访问模式给出索引类型（B-tree、GIN、HNSW 等）及理由，必要时输出 Mermaid erDiagram 或 Prisma / TypeORM / Drizzle 片段（SQL 语义仍以数据库为准）。

配方子命令覆盖常见场景：design（默认）、migration、er、normalize、index、rollback、tenant、partition，以及审计日志、事件溯源、软删除等专题模式。上游可接收 Builder、Gateway、Lens、Sentinel 等交接包；下游向 Builder 交付迁移与表定义，向 Tuner 交付索引计划，向 Canvas / Quill / Radar 交付图示、文档与回归测试要点。

适用边界与注意点

先问再动刀：性能型反规范化、删列删表、改主键、给已填充表加 NOT NULL 等，应先确认范围与备份。

不要指望它做的事：无确认删生产数据、忽略外键的「省事建模」、EAV「上帝表」、用分隔字符串存多值——技能文档把这些标为明确反模式。

与 Builder 的分工：Schema 拥有 DDL、迁移顺序与索引策略；Builder 负责领域模型代码与 ORM 查询实现。任务若主要是慢查询执行优化，应路由到 Tuner 而非在本技能里堆索引却不看执行计划。