返回全栈开发
PATH 02/LESSON 11/19 分钟

数据模型承载产品规则

从实体、关系、约束和迁移理解数据库设计。

课程全目录 · 选择章节

本课学习目标

  • • 实体 — 识别稳定对象
  • • 关系 — 表达对象连接
  • • 约束 — 保护不变量
  • • 迁移 — 安全演进结构

完成路径

阅读概念与案例 → 完成动手任务 → 勾选实践检查 → 回答检查点 → 保存完成记录。练习由你自行检查,不会假装成自动代码评分。

01 / 核心概念

数据表不是界面字段的简单复制。模型需要表达哪些事实必须唯一、哪些关系可以为空、哪些变化需要被保留。

约束越接近数据,越能防止多个入口写入互相矛盾的状态。

02 / 心智模型

01

实体

识别稳定对象

02

关系

表达对象连接

03

约束

保护不变量

04

迁移

安全演进结构

03 / 代码骨架

TYPESCRIPT / CONCEPT
model Task {
  id        String   @id @default(cuid())
  ownerId   String
  status    TaskStatus @default(PENDING)
  createdAt DateTime @default(now())
  owner     User @relation(fields: [ownerId], references: [id])
}

这是解释结构的代码骨架,外部函数与数据需要在实际项目中实现。

04 / 贯穿案例

放进真实情境里看

两位成员同时创建同名任务,或者任务所属用户已被删除。界面上的规则无法保证数据库中始终有一致的关系。

  1. 01

    从事实识别实体

    用户和任务是独立实体;任务保存 ownerId,状态只取允许值,并有创建时间与更新时间。

  2. 02

    把不变量放进数据库

    主键、防重复约束、外键和检查约束可以在并发写入时仍保护数据。唯一规则要明确范围,例如同一用户内唯一。

  3. 03

    设计迁移与删除策略

    新增必填字段时先考虑旧数据如何补齐;删除用户时决定任务是级联删除、匿名化还是保留审计记录。

05 / 动手做

用自己的产物检验理解

为 users 和 tasks 画关系图,列出主键、外键、状态约束;再写出“删除用户”时任务会发生什么。

完成时检查

  • 能阻止孤儿任务
  • 唯一性范围写清楚
  • 迁移覆盖已有数据

自动保存在当前浏览器,不会同步到账户。

继续到代码练习

06 / 检查点

用户名必须唯一,这条规则最应该放在哪里?

延伸阅读 · 原始资料