我犯过书中所有数据库设计的错误。有些错误我还犯过两次。最糟糕的部分是，糟糕的数据库设计不会立即产生影响——在你尝试添加一个功能并意识到你的架构让这变得不可能的时候，它会在六个月后伤害到你，那时候不得不进行痛苦的迁移。
最初看起来没问题的错误
1. 将所有内容存储在一个表中
一个包含47列的“用户”表。姓名、电子邮件、地址、偏好、订阅状态、最后登录、头像 URL、账单信息……当你需要添加“备用电子邮件”时，你就添加第48列。这就是技术债务产生的方式。
分成逻辑实体：用户、地址、订阅、偏好。更多的表格，简单的查询，更容易的维护。
2. 没有规划关系
“一个用户有一个地址”在六个月后变成了“一个用户有多个地址”。如果你使用JSON列来存储地址，那么现在你得重写每一个查询。如果你使用了一个带有外键的单独地址表，那只需一行代码修改。
3. 忽视索引
当你的应用只有1,000行时，它运行得很快。到达100,000行时，那条未索引的WHERE子句需要3秒。到达1,000,000行时，它超时了。在你过滤、排序或连接的列上添加索引。根据数据库性能研究，缺失索引是慢查询的最大原因。
4. 使用错误的数据类型
将电话号码存储为整数（前导零消失）。将货币存储为浮点数（0.1 + 0.2 ≠ 0.3）。将日期存储为字符串（祝你排序顺利）。从一开始就使用正确的类型——稍后更改需要迁移每一行。
设计过程
AI数据库设计师帮助你在编写任何SQL之前思考你的架构。描述你应用的数据需求，它将生成一个具有适当关系、索引和数据类型的标准化架构。
- 列出你的实体（用户、产品、订单等）
- 定义关系（一对多，多对多）
- 仔细选择数据类型
- 在频繁查询的列上添加索引
- 计划你将在6个月内添加的功能
规范化：简短版本
不要在两个地方存储相同的数据。如果客户的名字同时出现在客户表和订单表中，它们将会不同步。只存储一次，使用外键引用它。
相关工具
代码生成器 — 从你的架构生成ORM模型
API文档生成器 — 文档化你的数据模型
JSON格式化工具 — 格式化架构定义
API测试工具 — 测试你的数据库支持的端点