我让 AI 帮我设计了一个电商数据库，上线后差点没改死我

去年做一个小电商项目，我偷了个懒——直接跟 Claude 说"帮我设计一个电商数据库的 Schema"。Claude 很快给了我一份设计：users、products、orders、order_items，看起来挺标准的。

我当时觉得"挺好的嘛，省了我一个小时"，没怎么仔细看就开始写业务逻辑了。

两周后上线，问题来了：

1. 商品价格没有历史记录——products 表里只有一个 price 字段。我改了商品价格之后，之前的订单显示的也变成了新价格。因为 order_items 里只存了一个 productId，没有快照当时的价格。

1. 没有考虑软删除——用户删了账号，关联的订单数据也被级联删除了。客服说"这个用户的退款记录找不到了"。

1. 地址没有独立成表——用户地址直接放在 orders 里，用户改了地址后，旧订单的地址也变了。

这三个问题的根源是一样的：AI 设计 Schema 的时候只考虑了"数据存什么"，没有考虑"数据怎么变"。

数据库设计需要"业务直觉"

数据库设计跟写 CRUD 代码不一样。写代码错了可以改，Schema 设计错了改起来就要命了——因为数据已经存进去了。

AI 不擅长数据库设计的原因在于，好的设计需要预判未来：

• 价格会变吗？→ 需要在订单里冗余一份当时的价格
• 数据会被删吗？→ 需要软删除（deletedAt）而不是真删
• 一个用户有多个地址吗？→ 地址应该独立成表
• 以后会需要按什么维度统计？→ 需要冗余一些用于查询的字段
• 数据量会有多大？→ 大表需要考虑索引和分区

这些问题的答案取决于业务逻辑，而不是技术规范。AI 知道一对多关系怎么建，但不知道你的电商是卖衣服还是卖数字产品——前者需要库存管理和物流地址，后者不需要。

所以正确的协作方式是：你做设计决策，AI 做技术实现。

怎么把业务需求"翻译"成 AI 能理解的设计指令

直接说"帮我设计一个电商数据库"太模糊了。你需要做的是把业务需求结构化：

❌ 模糊的需求：
"我要做一个电商网站，帮我设计数据库"

✅ 结构化的需求：
"帮我设计数据库 Schema，业务场景如下：

1. 用户系统
   - 用户可以注册/登录（邮箱 + 密码）
   - 一个用户可以有多个收货地址
   - 用户有角色：普通用户 / 管理员

2. 商品系统
   - 商品有分类（一个商品只属于一个分类）
   - 商品有 SKU（规格），比如同一件衣服有不同颜色和尺码
   - 每个 SKU 有独立的价格和库存

3. 订单系统
   - 用户下单时，需要快照当时的商品信息和价格（防止后续改价影响历史订单）
   - 订单有状态流转：待支付 → 已支付 → 已发货 → 已完成 / 已取消
   - 支持退款（部分退款或全额退款）

4. 通用要求
   - 所有表都要有 createdAt、updatedAt
   - 不要真删数据，用 deletedAt 软删除
   - 金额字段用整数（分），不要用浮点数
   - 所有外键关联要明确 onDelete 行为"

看到区别了吗？后者把每个业务场景的关键决策都列出来了——一对多还是多对多、要不要快照、怎么处理删除、金额的精度。AI 拿到这个需求，设计出来的 Schema 就会靠谱得多。

AI 设计 Schema 的常见问题

就算你的需求写得很清楚，AI 生成的 Schema 仍然需要人工审查。这些是我遇到过的高频问题：

这些问题不需要你自己逐个检查——你可以让 AI 自查。生成 Schema 之后，再来一条："请检查这个 Schema 有没有缺少索引、外键行为未定义、或者字段类型不合适的问题。" AI 检查自己代码的效果通常比第一次生成好得多。