数据库模式 - 混合多对多和一对多关系

我有一个用户模型和一个任务模型。数据库模式 - 混合多对多和一对多关系

用户创建一个任务。这看起来很简单：任务有一个user_id foreign_key

但现在我们介绍共享。现在任务与用户有多对多的关系，但属于所有者。

我能： - 离开任务（也许它重命名为“owner_id”）的USER_ID - 并具有多对多连接表（user_tasks或shared_user_tasks）只有已经共享模式的任务。

我也可以： - 移除USER_ID的任务 - 并作出user_tasks纯许多人用布尔“is_owner”告诉我，如果该用户是所有者

或一对多的关系我可能： - 移除USER_ID的任务 - 并使user_tasks同时列出shared_user_id和owner_id 这意味着对于某些记载，shared_user_id和owner_id将是相同的号码（除上述更难查询）

，它是根据更多声音最佳实践？

谢谢你的时间。

而且，正如第一个答案所表明的那样（尽管我有点因为某种原因而不愿接受），从概念上讲，这两个角色是不同的。一个是任务负责人，另一个是与他们分享任务的人。

来源

2013-06-04 Squadrons

“真实”的正确答案将取决于如何使用这些表，但它听起来像选项1应该是您的解决方案（task_table.owner_id和单独的M：M user_tasks表）。即使任务所有者和任务用户共享相同的源表，它们在概念上也是不同的，应该这样对待。表连接的逻辑也会更清晰。

来源

2013-06-04 20:14:25 woemler

有趣的是，你说概念不同 - 我同意。我可以看到有user_tasks表为shared_user_tasks，我认为这是一个概念上不同于用户任务的对象。我也相信有一个查询是我无法轻松完成的，即查找用户共享的所有任务。我会编辑我的原始问题，向你展示我的意思。 – Squadrons

按照什么定义你的任务和什么使得最有效的SQL来考虑它。如果任务创建者不再“共享”任务该怎么办？在task_users表中拥有所有权标志会使这变得复杂。 – woemler

正常化到救援！也许.....（虽然可能有范围denormalise性能根据您的使用）

表用户 - 有关用户的信息存储（谁）表任务 - 关于任务的存储信息（任务是什么，它做了什么等）表UserTasks - M-> M映射。表UserTaskTypes - 百货（ “所有者”， “共享”， “顾问”， “经理人”，等等）

上UserTasks可能看起来像这样（TSQL）

CREATE TABLE UserTasks (
    [TaskID] INT, 
    [UserID] INT, 
    [UserTaskTypeID] INT, 

    FOREIGN KEY FK_UserTasks_TaskID ([TaskID]) 
      REFERENCES Tasks ([TaskID]), 

    FOREIGN KEY FK_UserTasks_UserID ([TaskID]) 
      REFERENCES Users ([UserID]), 

    FOREIGN KEY FK_UserTasks_UserTaskTypeID ([UserTaskTpyeID]) 
      REFERENCES UserTaskTypes ([UserTaskTypeID]), 

    PRIMARY KEY PK_UserTasks ([TaskID], [UserID], [UserTaskTypeID]) 
)

，并根据您你可以添加CHIS CONTRACTS来强制每个任务只有一个所有者等等。

为此选择一个聚集索引可能就像集群PK一样简单，但是你会在数据集上重排数据 - 你可能想要替代自动编号PK，并使用唯一约束来强制执行唯一性。

来源

2013-06-04 20:48:13

谢谢你的答案 - 我觉得这倾向于布尔is_owner user_tasks（我们只有拥有者而不是所有者）。我似乎来回翻转，并不能证明用户 - 任务 - user_tasks是最合理的设置。我将与我的老板讨论，并根据我们最常询问的内容得出结论。 – Squadrons

数据库模式 - 混合多对多和一对多关系

回答

相关问题