第一次用 Prisma：Schema、Migration 和 Client 是三件事

第一次跟着 Prisma 的官方教程动手时，我最容易混淆的是三个操作：在 schema.prisma 里改模型、把模型变化应用到数据库，以及生成应用代码要使用的 Prisma Client。

它们都和“数据库改好了”有关，但不是同一件事。

先在 Schema 里表达关系

当时练习的是很小的 User 与 Post 关系。一个 User 可以关联多篇 Post，邮箱设为唯一字段，authorId 可以为空。

model User {
  id    Int    @id @default(autoincrement())
  email String @unique
  posts Post[]
}

model Post {
  id       Int   @id @default(autoincrement())
  title    String
  authorId Int?
  author   User? @relation(fields: [authorId], references: [id])
}

这里保留的只是教学模型，不是任何生产数据库表。第一次理解的点是：关系不仅是一张表上的外键名，还要在 Prisma Schema 中体现双向关联和可空性。

三个动作不能直接划等号

• prisma migrate dev：为开发中的 Schema 变化创建并应用迁移，留下可版本化的 SQL 记录；
• prisma generate：依据当前 Schema 和 Generator 配置生成 Client 代码；
• prisma db push：让数据库结构朝 Schema 同步，但它不是替代迁移历史的日常生产部署流程。

我还了解到 prisma migrate deploy：它用于部署时应用已经存在的迁移，而不是在生产环境临时创造一份新迁移。

# 开发中：按 Schema 创建/执行迁移
pnpm exec prisma migrate dev --name add_post

# Client 代码生成
pnpm exec prisma generate

# 部署时：应用仓库内已有的迁移
pnpm exec prisma migrate deploy

这些是当时的学习路线；命令细节和生成器配置会随 Prisma 主要版本变化，实操应以当前官方文档和项目锁文件为准。

为什么生成 Client 还要另外做一步

当时通过 findMany() 这类 API 查询时，我才真正理解 Prisma Client 并不是在运行中直接解释所有 schema.prisma 内容：应用需要一份与 Schema 对应的客户端代码，构建与运行才能获得正确的类型和查询入口。

原始 Demo 还涉及 PostgreSQL、数据类型映射，以及某些接入方式下的 Prisma Accelerate 扩展。但 Accelerate 并不是每个 Prisma 项目都必需，这些条件要和具体 Data Source、客户端生成器区别开。

这次学习真正留下了什么

对我来说，Prisma 的抽象价值在于把数据模型、迁移和调用端的类型联系起来；它不意味着可以忽略真实 SQL、事务、查询计划或迁移兼容性。

做完这个 Demo，我至少分清了开发环境创建迁移、生成客户端代码和部署已有迁移这三个动作。真正迁移生产数据库时，还需要独立考虑迁移审查和兼容性检查。