How to Define a Schema for the Relationship of Events, Teams, and Members

Question

In Prisma, I'd like to model the following but I'm not really sure how.

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: ?????)
  ...
}

Constraints

1. Each team member must be in the Event.players
2. Each Event.player can only be assigned to one (or none) teams

Question

I have a feeling I need a many-to-many relationship here, but I'm struggling to figure this out. What do I relate Team.members to ?????. Am I even approaching this correctly?

More info (in case it's helpful)

I intend to create a drag-n-drop interface for creating teams. Those listed in Events.players but who have not yet been assigned as a Team.member will be in an unassigned bucket. Dragging them to a team, will assign them as a Team.member. But, I will want to query all players as events { players { id }} and events { teams { members { id }}}

Update

After giving this more thought, I'm thinking about a different way to solve this problem. Here's an updated schema I'd love your thoughts/input on.

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
}

Answer 1

Most of your model is accurate. There are a few minor changes you need to do:

1. Use of @relation directive: You need it only when a relationship is ambiguous. Example, self-relationship. You don't need it in your case. That is a traditional way of ORM thinking.
2. Nullability in relationships: Consider players: [User]! relationship. It says that players field cannot be null. It has to be a list. But it makes User as optional which means you can have players = [user1, null, user2]. You may not want this. This is applicable to almost all the to-many relationships.
3. User type should have a team field which is optional. There will be some users who will not be members of any team.

With the above adjustment, your schema will look like:

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!]!
}