Can a many-to-many join table have more than two columns?

Question

I have some tables that benefit from many-to-many tables. For example the team table.

Team member can hold more than one 'position' in the team, all the positions are listed in the position db table. The previous positions held are also stored for this I have a separate table, so I have

• member table (containing team details)
• positions table (containing positions)
• member_to_positions table (id of member and id of position)
• member_to_previous_positions (id of member and id of position)

Simple, however the crux comes now that a team member can belong to many teams aghhh. I already have a team_to_member look-up table. Now the problem comes how do I tie a position to a team? A member may have been team leader on one team, and is currently team radio man and press officer on a different team. How do I just pull the info per member to show his current position, but also his past history including past teams. Do I need to add a position_to team table and somehow cross reference that, or can I add the team to the member to positions table?

It's all very confusing, this normalization.

Answer 1

It's perfectly legitimate to have a TeamPositionMember table, with the columns

Team_Id
Position_Code
Member_Id
Start_Date
End_Date NULLABLE

And and a surrogate ID column for Primary Key if you want; otherwise it's a 3-field composite Primary Key. (You'll want a uniqueness constraint on this anyway.)

With this arrangement, you can have a team with any set of positions. A team can have zero or more persons per position. A person can fill zero or more positions for zero or more teams.

EDIT:

If you want dates, just revise as shown above, and add Start_Date to the PK to allow the same person to hold the same position at different times.

Answer 2

Yes, a many-to-many junction table can have additional attributes (columns).

For example, if there's a table called PassengerFlight table that's keyed by PassengerID and FlightID, there could be a third column showing the status of the given passenger on the given flight. Two different statuses might be "confirmed" and "wait listed", each of them coded somehow.

In addition, there can be ternary relationships, relationships that involve three entities and not just two. These tables are going to have three foreign keys that taken together are the primary key for the relationship table.

Answer 3

My first thought:

Give your many-to-many teams/members table an ID column. Every team-to-member relationship now has an ID.

Then create a many-to-many linking positions to team-member relationships.

This way, teams can have multiple members, members can have multiple teams, and members can have multiple positions on a per-team basis.

Now everything is nice and DRY, and all the linking up seems to work. Does that sound right to anyone else?

Answer 4

Sounds like you need a many-to-many positions to teams table now.

Answer 5

Your team_to_member table can indeed have an extra column position_id to describe (or in this case point to) the position the member has within that team.

Answer 6

Get rid of member_to_previous_position table. Just use member_to_positions and have these columns:

MemberToPositionID (autoincrement OK only)
MemberID
PositionID
StartDate
EndDate

Then to find current positions, you do:

select * 
from member_to_positions 
where EndDate is null