SQL數據庫中的計劃應用程序的表結構

我正在處理數據庫以保存應召信息計劃的信息。目前，我有一個看起來大約是這樣的結構：SQL數據庫中的計劃應用程序的表結構

Table - Person: (key)ID, LName, FName, Phone, Email 
Table - PersonTeam: (from Person)ID, (from Team)ID 
Table - Team: (key)ID, TeamName 
Table - Calendar: (key dateTime)dt, year, month, day, etc... 
Table - Schedule: (from Calendar)dt, (id of Person)OnCall_NY, (id of Person)OnCall_MA, (id of Person)OnCall_CA

我的問題是：隨着附表表，我應該離開它結構爲是，其中DT是一個獨特的密鑰，或者我應該予以重新排列使DT是不唯一的，並且表看起來像這樣：

Table - Schedule: (from Calendar)dt, (from Team)ID, (from Person)ID

，並有每一天多個條目，或將是有意義的只是使用：

Table - Schedule: (from Calendar)dt, (from PersonTeam)KeyID - [make a key ID on each of the person/team pairings]

一個團隊總是會有人打電話，但一個人可以一次呼叫多個團隊（如果他們在多個團隊中）。

如果完全不同的設置會更好地讓我知道！

感謝您的幫助！如果我的問題不清楚，我很抱歉。我學習速度很快，但對於每天使用SQL仍然相當新，所以我想確保在學習時使用最佳實踐，以免我養成不良習慣。

來源

2012-11-04 The Astronaut

我建議編輯你的問題標題。 – undone

是的，我剛剛做到了。第一個標題令人困惑，我甚至沒有意識到這一點。 –

（請考慮以下的建議，而不是批評。）如果表代表的實體，它往往是似乎最自然的由實體名稱（是否使用單數或複數是稱之爲*高*有爭議的，所以我沒有在這個頭上說什麼），就像'人'一樣。當另一個表本質上是兩個實體之間的多對多關係時，通常使用兩個實體的名稱來調用它。所以，如果你喜歡，可以考慮它是否會爲你工作更好，如果你叫'TeamIndex'表只是'Team'和'Teams'一個，'TeamPerson'（或者，也許，'PersonTeam'）。 –

在我看來，答案可能取決於團隊數量是否固定爲和相當小。當然，團隊的名稱是否是固定的也可能很重要，但這可能與列命名有關。

更具體地說，我的看法是這樣的：

如果業務需求是始終有召喚小和固定數量的人（比如，三），那麼它可能是更方便地分配三列在Schedule，一個是每一支球隊舉行任命的人的ID，即像當前的結構：

dt OnCall_NY OnCall_MA OnCall_CA 
--- --------- --------- ---------

與dt作爲主鍵。

如果團隊數量（在Team表中）也是固定的，那麼您可以像現在這樣在列名中包含團隊的名稱/指定者，但是如果團隊的數量超過三個，並且它只是這是僅限於三個Schedule隊的數量，那麼你可以只使用名稱，如OnCallID1，OnCallID2，OnCallID3。

但是，即使這一要求是固定的，它可能只變成固定今天，明天你的老闆說，「我們不再有固定數量的團隊（呼叫）的工作」，或者「我們需要將支持的團隊數量擴大到四個，我們可能需要在未來進一步擴展「。因此，一個更普遍的做法是你正在考慮在你的問題轉換到一個，那就是

dt Team Person --- ---- ------

其中的主鍵現在是dt, Team。

這種方式，您可以輕鬆地擴展/減少的人數在數據庫級的呼叫，而無需更改任何架構。

UPDATE

我忘了解決我原來的答覆（對不起）你的第三個選擇。開始。

你的第一選擇（目前實際執行的）似乎暗示每個隊可以只（不超過）一個人提出。如果您指定的代理ID，以個人/團隊對並使用這些按鍵在Schedule，而不是單獨的ID爲Person和Team，你可能會無法「每隊一人計劃」實施所提到的要求（或者，至少，這可能會有點麻煩），而使用單獨的密鑰，只需將Team設置爲組合鍵(dt, Team)的一部分即可完成，現在每天只有一個團隊完成。

而且，你可能有讓人變化團隊隨着時間的推移，如果他們在球隊中存在以這種方式迷戀，即用Schedule參考個人/團隊對困難。你可能將不得不改變在PersonTeam表中的隊伍參考，這將導致對歷史信息不實陳述：在人們對呼叫回頭看某一天的時候，顯示將是一個人的球隊，他們屬於現在，不是他們那時做的那個。

使用的人員和團隊獨立的ID在Schedule，另一方面，將允許你讓人們改變球隊自由，提供你不使(Schedule.Team, Schedule.Person)一個參考(PersonTeam.Team, PersonTeam.Person)，當然。

來源

2012-11-04 17:34:40

當前版本，每個團隊一列，可能不是一個好主意。由於您代表的團隊是一張表格（而不是一個枚舉或等價物），這意味着您期望隨着時間的推移添加/刪除團隊。這將迫使你添加/刪除列到表中，這往往是一個比添加/刪除幾行更大的任務。
的第二選項是通常解決這樣的問題。一個安全的選擇。您始終可以定義從Schedule（teamID，personID）到PersonTeam的額外外鍵約束，以確保您不會錯誤地將計劃任務分配給不屬於該團隊的人員。
第三選項是非常相當於第二，只有你對換PersonTeam複合自然鍵用於替代簡單的鍵。由於所述組合密鑰的兩個組成部分已經是代理人，因此添加這個附加組合並不具有優勢（就不變性等而言）。此外，它會變成一個非常簡單的N-M關係（PersonTeam），大多數DB經理/ ORM將很好地處理成更復雜的對象，這將需要自行管理。

由奧卡姆的剃鬚刀，我會刪除額外的代用鑰匙，並使用你的第二個選項。

來源

2012-11-04 17:49:35 jsalvata

你的回答，更加完整的，提醒我，我忘了解決OP的第三個選項，謝謝。 –

SQL數據庫中的計劃應用程序的表結構

回答

相關問題