[UML] Mapping a relation between objects in the same table

Question

Hello guys! I've ran into a design issue; in a project, i have three tables: League, Players, and an association table LeagueToPlayers that maps multiple to multiple connections between the first two (as a player can simultaneously play in two or more leagues):

League        Players              LeagueToPlayers
Id Name       Id Alias             LeagueId  PlayerId
=--------     ------------         ----------------
1  League A   1  Longcat           1        1
2  League B   2  Leeroy Jenkins    1        2
3  League C   3  xyz               2        1
4  League D   4  qw3rty            2        3
              5  Myrkgrav          3        2
                                   4        1
  (...)           (...)            4        3
                                   5        1

                                     (...)

My problem is that i now have to map a player to player relation. From my perspective, two things can be done: either an additional field is introduced to the Player table (mapping another PlayerId) - which is a pretty bad bet because in all odds this will be a 1..* relation - or another association table is created (not really loving the idea, but i guess there is no other way).

I'd like to hear your perspectives regarding this issue... any bright ideas?

Regards, Hal

EDIT: as mentioned in the comments, this is a metaphor. The type of objects present in the "Player" table varies a LOT (think two hundred distinct types) and they really must be mapped this way. The objects in the Player table may reference one another because they end up participating in the same process and, as such, they are related with one another. This connection is definitely 1..*

Answer 1

If it's 1:*, then put it on the * side (ex. parent_id on the child row for a hierarchy).

If it's *:*, use another correlation table.

Answer 2

If I had to maintain your DB after you were hypothetically gone, I'd pray you'd go with another correlation table mapping player to player - for good normalization practice, consistency and ease of maintenance.

This solution is also more flexible in the sense that it probably puts you in a better position if you need for whatever reason to extend the model.