Avatar of deleyd
deleyd
Flag for United States of America asked on

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

C# program has classes.

(I guess it doesn't matter this is C#. Any OOP language will do.)

one class represents a Team

other class represents a Player

A Team has a "List of Players"

A Player has a "List of Teams" he/she plays on.


Now, when a Player joins a Team, we need to update two lists: 

  • Team "List of Players"
  • Player "List of Teams"

This leaves open the possibility of having an inconsistent set of data. If we update one list and not the other.

Does this make sense? Perhaps a Team thinks a Player is on it's team, but nobody told the Player?

Or a Player thinks it's on a Team, but nobody told the Team?


Can we eliminate this possibility of having an inconsistent set of data?

(or is the data not really inconsistent?)

C#Databases

Avatar of undefined
Last Comment
deleyd

8/22/2022 - Mon
Scott Fell

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
Pavel Celba

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.
arnold

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.
Your help has saved me hundreds of hours of internet surfing.
fblack61
deleyd

ASKER
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;
}

Open in new window

Then, I'd need another class which is a list of all TeamPlayers:
class TeamPlayerList
{
    List<TeamPlayer> teamPlayerList;
}

Open in new window

Then, I have a class Team,
class Team
{
}

Open 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

arnold

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.
AndyAinscow

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.
⚡ FREE TRIAL OFFER
Try out a week of full access for free.
Find out why thousands trust the EE community with their toughest problems.
Pavel Celba

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;
    }

Open in new window

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

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();
}

Open in new window

 
ASKER CERTIFIED SOLUTION
Dustin Saunders

THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
See Pricing Options
Start Free Trial
GET A PERSONALIZED SOLUTION
Ask your own question & get feedback from real experts
Find out why thousands trust the EE community with their toughest problems.
deleyd

ASKER
Thank you everyone! I would like to give everyone credit. I greatly appreciate all the input.
All of life is about relationships, and EE has made a viirtual community a real community. It lifts everyone's boat
William Peck
deleyd

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