问题
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))
回答1:
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.
回答2:
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.
回答3:
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.
回答4:
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.
回答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.
回答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 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.
来源：https://stackoverflow.com/questions/774402/is-there-anything-wrong-with-having-a-table-with-one-column-mssql-server