数据库模式设计助手

它解决什么问题

从需求文档到可执行的建表语句之间，通常隔着一连串容易出错的手工决策：实体边界划在哪、关系是一对多还是多对多、主键用自然键还是代理键、哪些约束交给数据库还是留给应用层。这些决定一旦做错，后期要靠迁移脚本和数据修复来弥补。这个技能把整套推理显式化：它从用户访谈或规范文档中提取实体与关系，标注基数（1:1、1:N、M:N）和领域约束（唯一邮箱、正数价格、枚举状态），并在继续之前先把假设写下来，避免默认掉关键信息。

核心能力与工作流

技能按六个步骤推进：

• 需求收集与分析：识别实体、属性和关系，区分必需字段与可选字段，记录领域约束与基数。
• 实体与关系建模：为每个实体选择主键（优先代理整数或 UUID）；一对多在"多"端加外键，多对多用复合主键的连接表，一对一用共享主键或唯一外键。
• 规范化至 3NF：拆分传递依赖，仅在读查询密集处有选择地反规范化，并记录权衡。
• 约束与索引：用 NOT NULL、UNIQUE、CHECK、DEFAULT 在数据库层强制完整性；对外键列、WHERE / ORDER BY / GROUP BY 用到的列建索引，多列查询模式考虑复合索引。
• 生成 DDL：输出带全部列、类型、约束和索引的 CREATE TABLE 语句，使用 IF NOT EXISTS 保证幂等，并按依赖顺序排列，被引用的表先建。
• 验证与迭代：对照原始需求检查实体覆盖、关系正确性和完整性漏洞，再按反馈调整。

输出是可直接执行的 SQL，覆盖 PostgreSQL、MySQL、MariaDB、SQLite、SQL Server、Oracle 等关系库，也可配合 Flyway、Liquibase、Alembic、Prisma Migrate、Knex 做迁移管理。

适用边界

它只面向关系型数据库，不涉及文档库、图数据库或时序模型。多租户仅覆盖共享表加 tenant_id 与独立 schema 两种策略，行级安全需要引擎本身支持。BLOB 和大文本建议拆表外键存放，但具体分片策略仍需人工判断。给出的索引与反规范化建议是起点，真实性能要在查询负载下验证。