數據庫模式 - 混合多對多和一對多關係

我有一個用戶模型和一個任務模型。數據庫模式 - 混合多對多和一對多關係

用戶創建一個任務。這看起來很簡單：任務有一個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

數據庫模式 - 混合多對多和一對多關係

回答

相關問題