数据库架构设计助手

问题从哪来

新功能立项或重构时，表结构往往在 PR 里临时拼出来：VARCHAR(255) 遍地、金额用浮点、外键没约束、迁移不可回滚。等到流量上来，慢查询和脏数据才暴露，改 schema 的成本远高于一开始按访问模式建模。

技能怎么帮你做设计

你把领域实体、关系和可选的规模/数据库偏好说清楚，技能会按生产习惯产出完整 SQL（未指定时默认 SQL），并覆盖常见工程动作：

• 从零建模：design schema for {domain}，先域模型、再落到表与关系
• 规范化：对已有表做 1NF→3NF 检查，避免重复组与传递依赖
• 索引策略：外键与 WHERE/ORDER BY 列、复合索引列顺序与选择性
• 迁移：可逆的 UP/DOWN，强调先可空、回填、再 NOT NULL 等零停机思路
• 审查：对照清单核对主键、FK 的 ON DELETE、约束类型与 created_at/updated_at

文档里还整理了 OLTP/OLAP 取舍、反模式（如金额用 DECIMAL、日期勿存字符串）以及 MongoDB 嵌入 vs 引用等 NoSQL 要点。

适用边界

它输出的是设计稿与 SQL/迁移模板，不会替你连真实库执行、跑 EXPLAIN 或按 MySQL/PostgreSQL 方言自动分叉——扩展点里提到的多数据库变体、多租户、CQRS 等需你在对话里明确要求。复杂报表或读多写少场景，可能需要在 3NF 基础上有意识的反规范化，技能会按你描述的访问模式给建议，但最终仍要你用 staging 数据验证。