What are the tradeoffs between using object ID's vs stuffing the objects into other classes? [closed]

Question

EDIT: the great early responses made me realize that my question vis a vis tradeoffs would be more useful incorporating @Leo's variation.

I am developing a data model in Code-First EF and feel inexpert on what probably is pretty fundamental.

Given classes Team and Player, where a Team has N Players, the data model can be designed

1) either with the Players as member children objects:

class Team
{
    int Id;
    ICollection<Player> Players;
}

or 2) (REJECTED AS HAVING NO REAL BENEFIT) we can just pass around reference ID's to the players

class Team
{
    int Id;
    ICollection<int> PlayerIds;
}

or 3) implemented with foreign key ID's for model independence

class Team
{
    int Id;
}

class Player
{
    int Id;
    int TeamId;
}

I can see some clear benefits to the 3rd approach, as indicated below by @Leo. So perhaps my question would best be phrased, at this point, as "in what scenarios might one prefer to go with variation 1"?

Answer 1

Well, I guess you're right, you won't find many resources that outline how you should design you data layer and/or models. Actually, the resources you will find will most-likely depict different ways to do it and perhaps suggest what you should (or should not) do. However, I have found the subject to be extremely subjective and you should never isolate it from the context, what I mean is, only you should know which approach will best suit your circumstances because you are the one who has the best knowledge of your system's intrinsics. Both approaches look fine to me, what you should ALWAYS do is strive to keep loose coupling between sub-systems. Basically, this mapping...

class Team
{
    int Id;
    ICollection<Player> Players;
}

is making Teams dependant on Players, which is fine IF (and only if) it's a requirement that should never change. Furthermore, if Players will always belong to one and only one team then you can take another approach by keeipng your Team model/entity dependency free...

class Team
{
    int Id;
    string TeamName;
}

class Player
{
    int Id;
    int TeamId;
}

Database queries should not be a concern here, your presentation and model layer should try to abstract away from relations, if you can't...say, you need to display/present a team and its players then you will most-likely need 2 database queries(if you don't want to use joins and sanitize the duplicated fields...teams, in this case) and I don't see anything wrong with making 2 separate database queries.

Edit

I guess approach 1 makes coupling even tighter and you should always avoid it, imagine if by any chance you need to chance the name of the Player class, you'd have to make a lot of changes throughout your system. Furthermore, if you are exposing an API it might be even worse for your clients. But, as I said it all depends on the core requirements of your system...if these is a core (hard to change) requirement then you shouldn't worry about it.

"in what scenarios might one prefer to go with variation 1"?

Again, this all about requirements, if your requirements dictate that there is a relationship between Teams and Players then all approaches are fine as long as you can establish a relationship between the two entities.