简诗 AI 数据库范式设计

为什么值得聊这个话题

需求评审时一句“用户要有订单和评论”，落到代码里就是一堆 CREATE TABLE。很多人建表凭感觉：orders 里塞一个 shipping_address，products 里存 category_name。上线前相安无事，上线后字段开始重复，改一处要动三张表，查询越来越慢。这个技能要解决的就是这件事：让 AI 智能体在生成表结构时走一遍有章法的规范化流程，产出能直接执行的 DDL。

技能如何工作

核心能力可以拆成四块：

• 需求剖析：识别实体、属性和关系，先确认基数（1:1、1:N、M:N）、必填字段与领域约束（如邮箱唯一、价格为正、评分范围），把假设显式记录下来再动手建模。
• 规范化到 3NF：检查部分依赖与传递依赖，把存不下的问题拆成多张表；只有读多写少的查询模式才允许刻意反规范化，且必须记录权衡。
• 约束与索引：显式定义 NOT NULL、UNIQUE、CHECK、DEFAULT，对 JOIN 用到的外键列和 WHERE、排序、分组列建索引，必要时上复合索引。
• 输出 DDL：生成幂等的 CREATE TABLE 语句，被引用的表先建，保证脚本可直接执行。

它覆盖 PostgreSQL、MySQL、SQLite 等主流关系库，也兼容 Flyway、Liquibase、Prisma Migrate 等迁移工具的工作流。

容易踩的坑与适用边界

• 外键一定要显式定义，别指望应用层兜底；主键优先用代理键，而不是邮箱、SKU 这类会变的自然键。
• 循环依赖：两张表互相引用时先建一张，再 ALTER TABLE 补外键；PostgreSQL 可用延迟约束处理事务内的循环插入。
• 多态关联：别用 entity_type + entity_id 这种无法保证引用完整性的写法，拆成独立可空外键列加 CHECK 约束更稳妥。
• 大字段分离：BLOB 和长文本挪到附属表，保持主表行宽小。

还要留意边界：这个技能不会自动安装依赖、改系统权限、建持久化任务或执行下载内容。涉及删除、付款、部署等外部写入时，它会先展示目标与影响，等你明确确认才动手。