7.4 数据库设计的核心理念
Tip
养成"先设计，再编码"的习惯，并学会利用 AI 帮你审查数据库结构。
1. 为什么要学这个?
你做一个电商App。一开始为了省事，在 Order 表里用一个字符串存了地址："北京市海淀区xx路"。
后来业务变了，运费要按"省份"计算。 你傻眼了：几百万条历史数据全是字符串，怎么把"北京市"拆出来？
更糟的是，用户说要有两个地址（家和公司）。
你的 Order 表只能存一个，整个数据库架构崩塌，必须停机重构。
Schema（数据库模型）是地基。你可以随时给顶楼换窗帘（改代码），但绝没法在楼盖好后换地基。
2. 核心概念
📝 核心原则：Schema First (模型优先)。
2.1 📐 什么是 Schema First？
在写任何业务代码（Function/Component）之前，先定义好数据的形状。
- 不要上来就写页面。
- 先想清楚：我有几个表？它们怎么把手牵在一起？
2.2 🤖 AI 交叉验证法 ("炼蛊")
作为初学者，你自己设计的结构肯定有漏洞。 我们可以利用 AI 的多重人格来互相找茬：
- AI-1 (架构师)：负责根据需求出设计稿。
- AI-2 (黑客/DBA)：负责攻击这个设计，找出扩展性漏洞。
- AI-1 (架构师)：根据反馈修改，直到无懈可击。
流程图
graph TD
PRD[需求文档] -->|投喂| AI1[AI 架构师]
AI1 -->|生成| SchemaV1[初步 Schema]
SchemaV1 -->|投喂| AI2[AI 找茬员]
AI2 -->|批评| Feedback[发现漏洞]
Feedback -->|修正| AI1
AI1 -->|最终产出| SchemaFinal[健壮的 Schema]
style SchemaFinal fill:#e8f5e9,stroke:#2e7d32
3. 实战操作：如何用 AI 设计
第一步：让 AI-1 设计
"我需要做一个类似 Twitter 的应用。请根据 Prisma 语法设计数据库模型。包含 Users, Tweets, Likes。注意：一个用户可以点赞多条推文。"
第二步：让 AI-2 找茬 (关键!)
"这是一份数据库设计稿。请作为一个资深 DBA 找出其中的逻辑漏洞。比如：如果未来要加入'转发'功能，目前的结构支持吗？如果用户注销了，他的推文会被误删吗？"
4. 避坑指南
| ❌ 不要这样做 | ✅ 应该这样做 | 💡 为什么 |
|---|---|---|
使用拼音命名 YongHu |
使用英文单数 User |
代码是国际通用的，拼音显得极其业余且难以维护。 |
| 用字符串存时间 | 使用 DateTime 类型 |
"2024-01-01" 只是文字，数据库没法帮你算"3天前是几号"。 |
| 忽视"多对多"关系 | 设计中间表 | 一个学生可以选多门课，一门课也有多个学生。直接存数组会死得很惨。 |
5. 真实案例
Story
2000年，"千年虫" (Y2K) 危机
上世纪60年代，为了节省昂贵的存储空间，程序员在设计数据库时，只用了2位数存年份（如 98 代表 1998年）。这在当时看起来很聪明。但到了2000年，系统把 00 识别成了 1900年。全球银行业务错乱、航班时刻表崩溃。全世界花了约 3000亿-6000亿美元 来修复这个因为"设计短视"留下的地基隐患。
Vibe心法：今天为了省事而偷的懒，明天都会变成修正成本高昂的黑洞——像建筑师一样思考未来，而不是像修补匠一样只看眼前。
6. 本章小结
- 📐 先画图：永远不要在没设计好 Schema 之前就开始写代码。
- ⚔️ AI 互搏：让一个 AI 设计，让另一个 AI 找茬，这是新手不仅不犯错，还能超越老手的秘诀。
- 🔭 远见：设计时多问一句"如果是明年，这个结构还撑得住吗？"