11. 数据库设计范式与反范式

1. 范式定义

**范式（Normalization）**是关系数据库设计的一套标准，用于减少数据冗余、避免更新异常。每提升一级范式，约束条件更严格。

1NF（第一范式）：原子性

每个属性值不可再分。

❌ 违反 1NF：
users 表
┌────┬──────┬─────────────────┐
│ id │ name │     phones      │
├────┼──────┼─────────────────┤
│ 1  │ 张三  │ 13800000000,139 │  ← 逗号分隔，可再分
└────┴──────┴─────────────────┘

✅ 符合 1NF：
users 表
┌────┬──────┐
│ id │ name │
└────┴──────┘

user_phones 表
┌────────┬─────────────┐
│user_id │   phone     │
├────────┼─────────────┤
│   1    │ 13800000000 │
│   1    │ 13900000000 │
└────────┴─────────────┘

2NF（第二范式）：消除部分依赖

非主属性完全依赖于整个主键（针对复合主键）。

❌ 违反 2NF：
选课表 (student_id, course_id) → 成绩, student_name
  student_name 只依赖于 student_id（部分依赖）

✅ 符合 2NF：
选课表: (student_id, course_id) → 成绩
学生表: student_id → student_name

3NF（第三范式）：消除传递依赖

非主属性不依赖于其他非主属性。

❌ 违反 3NF：
学生表: student_id → name, dept_id, dept_name
  dept_name 依赖于 dept_id（传递依赖：student_id → dept_id → dept_name）

✅ 符合 3NF：
学生表: student_id → name, dept_id
院系表: dept_id → dept_name

BCNF（巴斯-科德范式）

每个决定因素都是候选键。

❌ 违反 BCNF：
教师授课表: (teacher_id, course_id) → classroom
  teacher_id → classroom（一位教师只在一个教室上课）
  但 teacher_id 不是候选键（一位教师可教多门课）

✅ 符合 BCNF：
拆分：
教师教室表: teacher_id → classroom
授课表: (teacher_id, course_id)

2. 范式速查表

3. 反范式化

**反范式（Denormalization）**是故意违反范式，引入冗余以换取查询性能。

3.1 反范式场景

3.2 冗余同步策略

-- 方案 1：应用层双写
BEGIN;
UPDATE users SET name = '张三' WHERE id = 1;
UPDATE orders SET user_name = '张三' WHERE user_id = 1;
COMMIT;

-- 方案 2：触发器（数据库层）
CREATE TRIGGER sync_user_name
AFTER UPDATE ON users
FOR EACH ROW
BEGIN
    UPDATE orders SET user_name = NEW.name WHERE user_id = NEW.id;
END;

-- 方案 3：CDC（最终一致）
Debezium 捕获 users 变更 → Kafka → 消费者更新 orders

-- 方案 4：定时任务
每小时汇总更新冗余字段（适合容忍延迟的场景）

4. 多租户 SaaS 场景的范式抉择

SaaS 平台的数据库设计在范式与反范式之间需要更精细的权衡，尤其是多租户架构。

4.1 三种多租户数据模型

共享表模型的反范式设计：

-- 订单表（共享模型）
CREATE TABLE orders (
    id          BIGINT PRIMARY KEY,
    tenant_id   INT NOT NULL,          -- 分区键
    user_id     INT NOT NULL,
    total_price DECIMAL(10,2),
    user_name   VARCHAR(100),          -- 反范式：冗余用户名，避免 JOIN
    status      SMALLINT,
    created_at  TIMESTAMP,
    -- 索引必须包含 tenant_id 在前
    INDEX idx_tenant_created (tenant_id, created_at)
);

-- 查询时必须带 tenant_id 条件（防止跨租户数据泄露）
SELECT * FROM orders
WHERE tenant_id = :tenant_id AND status = 1
ORDER BY created_at DESC;

4.2 反范式化的数据一致性保障

对于租户级冗余字段，推荐使用 事件驱动 + 最终一致 方案：

users 表更新 name ──► Debezium CDC ──► Kafka Topic ──►
    Consumer 更新 orders.user_name（同一租户内批量更新）

补偿机制设计：

-- 添加 last_synced_at 字段，发现同步延迟时告警
ALTER TABLE orders ADD COLUMN user_name_synced_at TIMESTAMP;

-- 定时校验任务（低峰期运行）
SELECT COUNT(*) FROM orders o
JOIN users u ON o.user_id = u.id
WHERE o.tenant_id = :tenant_id
  AND o.user_name <> u.name;

5. 设计原则

数据库设计黄金法则：

1. 先按 3NF 设计，消除明显冗余和异常
2. 评估查询模式（Query Pattern），针对性反范式
3. 反范式时，必须有数据一致性保障方案
4. 记录反范式的理由和补偿机制
5. 定期复盘：反范式带来的收益是否值得维护成本

常见误区：
❌ 盲目追求 3NF（过度设计，JOIN 过多）
❌ 全部反范式（数据一致性问题爆炸）
❌ 不做文档（后人无法理解冗余字段的同步逻辑）

---

## 延伸阅读

- [SQL 注入与安全防护](https://plumephp.com/database-sql-injection/)
- [MySQL InnoDB 存储引擎](https://plumephp.com/database-mysql-innodb/)