多层级SaaS应用Prisma数据库架构反馈请求及关系约束疑问

我正在构建SaaS应用的User -> Organisation -> Project多层级账户流程，需要实现以下需求：

• 用户可拥有并隶属于多个Organisation；
• 一个Organisation可包含多个Project；
• 一个Project可关联多个用户，但仅限该Organisation下的用户。

目前我的Prisma架构已基本实现前两点，但对第三点存在疑问：是否需要在数据库层面强制执行该关系？还是仅在代码逻辑中处理（例如添加用户到Project前，先校验该用户是否属于对应Organisation）？

当前架构图 #

当前Prisma架构代码 #

（注：我使用了显式的m-n关联UserOrganisation，以便后续添加更多字段）

model User {
  id        String   @id @default(cuid())
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt

  email     String @unique
  firstName String
  lastName  String

  password Password?

  organisations UserOrganisation[]
  projects      Project[]
}

model Password {
  hash String

  userId String @unique
  user   User   @relation(fields: [userId], references: [id], onDelete: Cascade, onUpdate: Cascade)
}

model UserOrganisation {
  createdAt DateTime @default(now())

  userId String
  user   User   @relation(fields: [userId], references: [id], onDelete: Cascade, onUpdate: Cascade)

  organisationId String
  organisation   Organisation @relation(fields: [organisationId], references: [id], onDelete: Cascade, onUpdate: Cascade)

  @@id([userId, organisationId])
  @@unique([userId, organisationId])
}

model Organisation {
  id        String   @id @default(cuid())
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt

  name     String
  users    UserOrganisation[]
  projects Project[]
}

model Project {
  id        String   @id @default(cuid())
  createdAt DateTime @default(now())

  name String

  users User[]

  organisationId String
  organisation   Organisation @relation(fields: [organisationId], references: [id], onUpdate: Cascade, onDelete: Cascade)
}

解答建议 #

优先在数据库层面强制执行约束 #

数据库约束是数据一致性的最后一道防线，能彻底避免代码逻辑漏洞、直接数据库操作（如手动执行SQL）导致的数据错误。针对你的场景，可通过调整Prisma架构实现：

1. 替换Project与User的直接关联为显式中间表
   创建UserProject中间表，同时关联User、Project和Organisation，通过唯一约束和外键确保用户属于项目所在组织：

model UserProject {
  userId         String
  user           User         @relation(fields: [userId], references: [id], onDelete: Cascade)
  projectId      String
  project        Project      @relation(fields: [projectId], references: [id], onDelete: Cascade)
  organisationId String
  organisation   Organisation @relation(fields: [organisationId], references: [id], onDelete: Cascade)

  @@id([userId, projectId])
  // 确保用户在该组织下的关联记录存在
  @@unique([userId, organisationId])
  // 确保项目所属组织与中间表的组织ID一致
  @@unique([projectId, organisationId])
}

2. 调整User和Project模型的关联配置
   将原直接关联替换为通过UserProject的关联：

model User {
  // ... 其他字段
  organisations UserOrganisation[]
  projects      UserProject[] // 替换原Project[]
}

model Project {
  // ... 其他字段
  users UserProject[] // 替换原User[]
  organisationId String
  organisation   Organisation @relation(fields: [organisationId], references: [id], onUpdate: Cascade, onDelete: Cascade)
}

修改后数据库会自动校验：

• 用户必须属于项目对应的组织
• 项目的组织ID与中间表的组织ID完全匹配

代码逻辑校验仍需保留 #

即便有数据库约束，代码层面的校验也不能省略：

• 提前返回友好错误提示（如用户不属于该组织时，直接告知用户，无需等待数据库抛出异常）
• 减少无效数据库请求，提升系统性能

折中方案：暂不修改架构的处理方式 #

如果短期内不想调整数据库结构，仅在代码逻辑中校验也可行，但需注意：

• 覆盖所有添加/修改用户-项目关联的入口（包括API接口、后台任务等）
• 禁止直接通过SQL或数据库管理工具修改关联数据，避免绕过校验

内容的提问来源于stack exchange，提问作者Kyle Lambert