Teams has List of Players; Player has list of Teams. Avoid inconsistencies?

This is really more about your database set up.  I think if you have your schema like below where you have a table of players with their basic contact data, teams with just their name and captain and then a table of the team rosters, it will be easier to understand.

Players
PlayerID
Name
Address
Phone
Email

Teams
TeamID
Team_Name
Division
Captian

TeamRoster
RosterID
TeamID
PlayerID
PlayerNumber

No, there can be no inconsistencies observed if you implement it correctly.
You have two lists "Players" and "Teams" and you have the third list of couples. Each couple of Player-Team (in database world this represents a relation M:N) represents two values in one row.

Deleting the player or team also requires to delete all occurrences of such object from the list of couples or prohibit such deletion. Both requirements are achievable by relational integrity - Each player in the Players list represents unique Primary key in the list, the same is valid for each team in Teams list. Rows in the list of couples will contain two Foreign keys each one pointing to appropriate list of Primary keys...

If you will handle the list of couples incorrectly then you may observe duplicate couples which you may simply ignore or avoid by unique index creation on the list of couples (very easy in database world).

Of course, some players will have no team assigned and some teams can exist without players which is just a real scenario.

You would use a transaction to add a player to the players list

your business logic, can a player be a member of multiple teams?
Single league/multi league structure?

Associate the player with a team.
One way is to use an example provided.
The issue in the design, can player move among teams?
Do you need to maintain a record of team/player associations?
Are you considering including a schedule, results, etc.

So if I make another class, TeamPlayer, or PlayerTeam, and that class is, well, has one player and one team:

class TeamPlayer
{
    Team team;
    Player player;
}

Select allOpen in new window

Then, I'd need another class which is a list of all TeamPlayers:

class TeamPlayerList
{
    List<TeamPlayer> teamPlayerList;
}

Select allOpen in new window

Then, I have a class Team,

class Team
{
}

Select allOpen in new window

And if I want to find out what players are on the Team, I need to search through the TeamPlayerList, and find all the entries for my Team, and glean from that all the Players.

Doesn't seem right.

x

What are you going towards?

are you looking to build a structure within C# where you poppulate the player/team
to then pass it to a function to insert it into a DB?

or this is something else that you need to maintain in memory while having the DB be a more permanent repository
when the process starts?

Within the code, you do not need to have it structured.

Much depends on your need, you could have the object structure, player, parameter of info that you want, team, etc.
within a single object.

To store something in a DB, does not mean you have to replicate the structure of how the data is stored, managed to be part of your code?

i.e. you do not have folders on your desk identifying departments and then employees and you have to manage a set of files that tells you which employee is in which department.
you have a list of employee, the department, etc. when you need to have something done.

The breakdown you are doing in the code, would suggest you would have a complex scheme that you would have to pull/reference different, hashes or arrays to combine the lists to include a structure as was suggested for the database that has a list of object that references a player from the player list, a team for the team's list and so an and so forth.
Your object creation lists will likely exceed the demand on memory allocation more than the simple
1) player A, member of Team 1, etc.
if that is really needed, versus sending a simple query to the DB.

The classical database solution is as Scott said.   A third table which contains a 'couple' - the team and the player.  They there is only one location that has to be maintained when anything changes.

You should implement the TeamPlayers class as a list or array of tuples, e.g.:

    public class Team
    {
        string TeamName;
    }
    public class Player
    {
        string PlayerName;
    }
    public class TeamPlayerList
    {
        List<Tuple<Team, Player>> TeamPlayerList;
    }

Select allOpen in new window

To have some database engine in the background would be a big plus.

Keep the list of teams of each player and the list of players of each team private.
Only expose a read-only version of those lists and add public methods to handle the changes and keep the consistency.

public class Team
{
    List<Player> players;
    public void Add(Player player)
    {
        player.AddTo(this);
        players.Add(player);
    }
    public void Remove(Player player)
    {
        player.RemoveFrom(this);
        players.Remove(player);
    }
    public ReadOnlyCollection<Player> Players => players.AdReadOnly();
}
public class Player
{
    List<Team> team;
    internal AddTo(Team team) => team.Add(team);
    internal RemoveFrom(Team team) => team.Remove(team);
    public ReadOnlyCollection<Team> Teams => teams.AdReadOnly();
}

Select allOpen in new window

 

Thank you everyone! I would like to give everyone credit. I greatly appreciate all the input.

Thank you everyone! I would like to give everyone credit. I greatly appreciate all the input.