2016-09-19 57 views
0

以下方案将在关系数据库中实现。用于处理项目列表的表结构

我有以下情况: 有多个用户,都是唯一的。每个用户可以属于一个或多个“团队”。每个团队可以拥有未知数量的用户。

到目前为止,我得到的是,我应该与所有的队伍和所有的用户有一张桌子。 但是关于如何存储用户所属的团队,我是否需要为他所属的每个团队ID添加一个字段?我是否也需要确定他可以参加的比赛的数量或者是否可以有一定的限制? (如何存储一个列表,在其他应用程序中的限制是可用的内存)。

理想情况下,我想要一个结构,可以让我轻松查找用户属于哪个团队。

在团队表中也有类似的问题,我是否也需要定义团队中用户的限制?在这种情况下,我需要为团队中的每个用户提供一列吗?

最后,这个例子应该避免的东西,我应该看看结构不同?如果是这样,请提供一个例子。

我不是在寻找代码的例子,只是关于如何建立这些关系的例子。

还接受一些关于哪些数据库结构类型用于每种类型的问题的文档的建议。

回答

0

你的问题是所谓的多对多关系

你的数据库应该是这样的

用户表包含(IdUserName,Password,...其他栏)

团队表包含(Id,Name,..其他列)

UserTeamsUserIdTeamId,其他列)

现在你有一个表UserTeam 2个选项

  1. 两个用户名和TeamId是主键和外键:这意味着每个用户不能在同一个团队中注册两次,但可以注册很多但唯一的团队
  2. UserId和TeamId都是外键,并且您有另一个主键ID:此结构将允许您举例跟踪用户团队的历史记录,例如,如果您添加了加入日期(必填)和离职日期(可选),并且在用户离开团队时更新它,并且您需要添加一些用户无法在同一团队中注册的约束对于同一用户标识和团队标识的两个记录,请假日期为空。

第二结构编码将是如下:

UserTeams

  • Id:主键
  • UserId:外键引用Users
  • TeamId:外键参考Teams表格
  • DateOfJoin:需要时间字段
  • DateOfLeave:可选的时间字段,将每当用户离开球队

平时我比较喜欢第二种方法,可以提供所需的结构较少的更多的细节来填充。

希望这将帮助你

+0

我真的很喜欢你在第二种情况下的方法,我没有想那么远,但实际上这符合我心中的想法! 感谢你和Ghost的回答,我现在有了一个很好的主意。非常感谢! – Danyjex

+0

请接受我的回答,如果您觉得有用,请投票 – Monah

0

你是对的。您将拥有一个用于用户,团队和连接它们的表格的表格(UserTeam也许)。 UserTeam表将存储用户和单个团队的ID;如果该人员在多个团队中,则会有多行。

就限制而言,这是一个需求问题而不是数据库问题。你当然可以限制它,但应该不是一个技术问题。

这里是MS SQL Server中的表结构:

DECLARE @User TABLE (
    UserID INT, 
    UserName NVARCHAR(200) 
) 

DECLARE @Team TABLE(
    TeamID INT, 
    Name NVARCHAR(200) 
) 

DECLARE @UserTeam TABLE (
    UserID INT, 
    TeamID INT 
) 
+0

所以如果限制取决于问题,如果我认为在1种情况下用户可以从1到1000的团队的任何地方都有。为了保存每个用户所属团队的名单,是否有一张纯粹的表格有意义? 所以我只会将“list”的id存储在用户表中,而不必读取1000个团队,如果我想读取1个用户的整个行。 – Danyjex

+0

适当的表格设计将在与用户表格或团队表格分开的表格中每行1个用户+1个团队。 – UnhandledExcepSean

+0

你的意思是说我会摆脱用户表下的“团队”列。相反,我会有一个表,其中每个用户会有多行,每行只有一个团队。所以,如果我想找出用户属于哪个团队,我会查询该表中的“X”用户。 此外,原因是因为任何数据库都经过优化,不断添加更多的行而不是列?而且,这样做会通过牺牲内存为我提供更好的查询时间。 – Danyjex