Is there anything wrong with having a table with one column? (MSSQL Server)

Question

Consider the following scenario:

Tables:

• Employee (EmpId(PK), Name)
• TeamMembers(TeamId(PK), EmpId(PK))
• Project(ProjId(PK), TeamId)

I really want to avoid using composite PK, but the only way I see out of the problem is creating a Team table with only 1 column TeamId(PK) (i do not want to store any info associated with the team other than its members) (EDIT: if I create a team table, i'll add TeamMeberId to TeamMembers table and make it a PK)

Another problem with current setup is that I can't set a relationship for TeamId between Project and TeamMebers tables

Should I just create a 1 column Team table? What's the best approach in this case?

EDIT

just to clear things up, the only thing I want to know about that team is its existance, no additional info of any kind

EDIT2

Tables New Design (anything wrong with it?):

• Employee (EmpId(PK), Name)
• Team(TeamId(PK))
• TeamMembers(TeamMemberId(PK), TeamId(FK), EmpId(FK))
• Project(ProjId(PK), TeamId(FK))

Answer 1

does EmpId really need to be a primary key in your TeamMembers table? you could just say that each team has many employees, and the relationships work out.

Answer 2

If the only thing interesting about a team is the fact that it exists, then there is nothing wrong with a Team table with just one column: TeamId. It ensures referential integrity from the TeamMembers and Project tables.

But I do not understand your objection against a composite PK. The columns TeamId and EmpId in the TeamMembers table are alreay a composite primary key.

Answer 3

There is nothing wrong with this scenario. I'd do it.

On the other hand, you could hold other information in your Team table like a team Name or something.

Answer 4

There is nothing wrong with a 1 column table. However you might want to consider what other attributes your Team table could have. For instance, a team name?

For the relationship between project and employees, you merely have to join through the TeamMembers table.

Answer 5

Since it looks like there is a 1-to-1 relationship (correct me if I'm wrong) between Project and TeamMembers and you don't want to store additional info about the team, wouldn't it be easier to get rid of the TeamMembers table and go with a many-to-many linking table between Project and Employee

Employee (EmpId(PK), Name)
EmployeeProjects(EmpId(PK), ProjId(PK))
Project(ProjId(PK), <other project info>)

but to answer your original question. There is nothing particularly wrong with having a single column table.

Answer 6

This is how I would structure the tables

1. Employee (EmployeeId(PK), Name)
2. Team (TeamID(PK))
3. TeamMembers(TeamMembersID(PK), TeamId, EmployeeId)
4. Project(ProjectID(PK), TeamId)

I like to have a PK being the table name, suffixed with ID.
This convention does have the side affect of sometimes creating seemingly redundant primary keys (as TeamMembersID) but it solves your composite key problem.