Is there something wrong with a single column table? (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 a composite PK, but the only way I can see from the problem is to create a Team table with only one TeamId (PK) column (I don't want to store information related to a team other than its members) ( EDIT : if I will create a team table, I will add TeamMeberId to the TeamMembers table and make it PK)

Another problem with the current setup is that I cannot establish a relationship for TeamId between the Project and TeamMebers tables

Should I just create a column table of 1 column? What is the best approach in this case?

EDIT

just to clarify the situation, the only thing I want to know about this team is its existence, no additional information about any kind

EDIT2

Tables New design (is something wrong?):

• Employee (EmpId (PK), name)
• Team (TeamID (PC))
• TeamMembers (TeamMemberId (PK), TeamId (FK), EmpId (FK))
• Project (ProjId (PK), TeamId (FK))

Answer 1

If an interesting team is the fact that it exists, then there is nothing wrong with the Team table with one column: TeamId . It provides referential integrity from the TeamMembers and Project tables.

But I do not understand your objection to the composite PC. The TeamId and EmpId in the TeamMembers table represent a composite primary key.

Answer 2

There is nothing wrong with this scenario. I would do that.

On the other hand, you can store other information in your Team table, for example, the name of the team or something like that.

Answer 3

There is nothing wrong with the column table. However, you might think about what other attributes your team table might have. For example, the name of the team?

For the relationship between the project and the staff, you just need to join the TeamMembers table.

Answer 4

should EmpId really be the primary key in your TeamMembers table? you can simply say that each team has a lot of employees, and relationships are developing.

Answer 5

Since it seems that there is a 1 to 1 relationship between Project and TeamMembers (correct me if I am mistaken), and you do not want to store additional information about the team, it would be easier to get rid of the TeamMembers table and go with a link to the link table between Project and employee

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

but answer your original question. There is nothing special about the fact that you have one column table.

Answer 6

This is how I would structure the tables

• Employee (EmployeeId (PK), name)
• Team (TeamID (PK))
• TeamMembers (TeamMembersID (PK), TeamId, EmployeeId)
• Project (ProjectID (PK), TeamId)

I like it when PK is the name of the table, with index ID. This convention has a side effect, sometimes creating seemingly redundant primary keys (like TeamMembersID), but it does solve your difficult task.