【问题标题】:How to Define a Schema for the Relationship of Events, Teams, and Members如何为事件、团队和成员的关系定义架构
【发布时间】:2019-05-28 06:43:11
【问题描述】:

在 Prisma 中,我想对以下内容进行建模,但我不确定如何。

type Event {
  id: ID! @unique
  players: [User]! @relation(name: "EventPlayers")
  teams: [Team]! @relation(name: "EventTeams")
  ...
}

type User {
  id: ID! @unique
  eventsPlayed: [Event]! @relation(name: "EventPlayers")
  ...
}

type Team {
  id: ID! @unique
  event: Event! @relation(name: "EventTeams")
  members: [User]! @relation(name: ?????)
  ...
}

约束

  1. 每个team member 必须在Event.players
  2. 每个Event.player 只能分配给一个(或没有)团队

问题

我觉得我需要一个多对多的关系,但我正在努力解决这个问题。我将Team.members 与 ????? 联系起来是什么。我是否正确地接近这个?

更多信息(如果有帮助)

我打算创建一个拖放界面来创建团队。那些在Events.players 中列出但尚未被分配为Team.member 的人将在unassigned 存储桶中。将它们拖到一个团队中,会将它们分配为 Team.member。但是,我想以events { players { id }}events { teams { members { id }}} 查询所有玩家

更新

在考虑了更多之后,我正在考虑一种不同的方法来解决这个问题。这是一个更新的架构,我很喜欢你的想法/意见。

type Event {
  id: ID! @unique
  users: [EventUser!]!
  teams: [Team!]!
  title: string
}

type EventUser {
  event: Event!
  user: User!
  role: EventRole!
}

type User {
  id: ID! @unique
  events: [EventUser!]!
  name: string
}

type Team {
  event: Event!
  members: [EventUser!]!
  name: string
}

enum EventRole {
  ADMIN
  COORDINATOR
  JUDGE
  PLAYER
  REVIEWER
  SPONSOR
}

【问题讨论】:

    标签: graphql prisma prisma-graphql


    【解决方案1】:

    您的大部分模型都是准确的。您需要做一些小改动:

    1. @relation 指令的使用:仅当关系不明确时才需要它。例如,自我关系。在你的情况下你不需要它。这是一种传统的 ORM 思维方式。
    2. 关系中的可空性:考虑players: [User]! 关系。它说玩家字段不能为空。它必须是列表。但它使User 成为可选的,这意味着您可以拥有players = [user1, null, user2]。你可能不想要这个。这适用于几乎所有 to-many 关系。
    3. User 类型应该有一个可选的 team 字段。会有一些用户不是任何团队的成员。

    通过上述调整,您的架构将如下所示:

    type Event {
        id: ID! @unique
    
        # Note DOUBLE EXCLAMATION
        # Ensure that User, as well as players, are not null.
        players: [User!]!
    
        # Note DOUBLE EXCLAMATION
        # Ensure that Team and teams are not null.
        teams: [Team!]!
    }
    
    
    type User {
        id: ID! @unique
    
        eventsPlayed: [Event!]!
        team: Team
    }
    
    
    type Team {
        id: ID! @unique
    
        event: Event!
        members: [User!]!
    
        # Added an extra key for keeping track of past events if required
        pastEvents: [Event!]!
    }
    

    【讨论】:

    • 感谢您的回复,以及对双重感叹号的解释。我肯定想错了。问题是,每个Team 只存在于一个事件中,因此将过去的事件显示为团队类型的一部分是没有意义的。用户可以属于多个团队。我添加了一个新架构。我喜欢你的想法。
    • @ChrisGeirman,看起来不错。另外,如果你不需要EventRole,那么你可以去掉EventUser 模型。而且,您缺少Team 的 ID。否则,它是完美的。
    • 谢谢!我一直在玩它,到目前为止效果很好。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2017-09-09
    • 1970-01-01
    • 2014-01-06
    • 2011-05-04
    • 2011-06-16
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多