卡在複雜的數據庫設計上

我正在開始一個新項目。這個項目目前正處於規劃和設計階段，但我可以考慮一個解決方案，但它似乎並不是最優化或組織的障礙。任何幫助表示讚賞。卡在複雜的數據庫設計上

我有以下用例：

用戶可以創建一個事件（如在物理事件，如賽跑或節），這是「協調器」。
可以爲此新事件分配零個或多個工作人員來處理事件。他們將可以訪問有關該事件的其他工具/數據。
此事件可能有零個或多個參與者通過此服務註冊。
沒有登記的用戶可能會發現關於該事件

我想換我圍繞如何創建有效存儲該信息的數據庫頭詳細信息的頁面。特別是如果我們計劃擴展到誰知道有多少事件。現在，我有以下的想法。數據庫設計還有更多，但它主要是用於驗證和用戶數據的數據，所以我沒有包括它 - 讓我知道是否有助於看到完整的設計。

USER 
----------- 
id (pk) 

EVENT 
----------- 
id (pk) 
coordinator (fk, references USER.id) 
page 
workers 
participants 

//workers and participants are lists of USER.ids

這很簡單，但我只能看到它在一個方向上的效率，而不是兩個。查詢查找任何給定事件的工作人員和參與者將非常簡單，但對於任何給定用戶查找事件將非常麻煩。

任何想法/評論都會非常有幫助。謝謝。

來源

2011-10-11 Tim

您可以在類似MongoDB的地方使用ID數組，但不能在基於SQL的數據庫（如SQL Server或MySQL AFAIK）中高效地使用數組。相反，如果您不使用基於非SQL的數據庫，請使用映射表來存儲事件與工人以及事件與參與者之間的關係。

來源

2011-10-11 03:33:17 GregL

我不熟悉蒙戈或NoSQL的。不過謝謝你。 – Tim

是的，我也不是很熟悉它們。但是我喜歡的東西之一就是它實際上是一個有效的數據類型，它有一個字段作爲ID數組，這很容易查詢。 – GregL

這實際上應該很容易放入RDMS。您只需要爲工人和參與者提供一系列多對多關係。您還可以在此表中存儲您需要的任何特定於該事件的該參與者/工作人員的任何內容。

User 
---- 
ID 

Events 
------ 
ID 

Participants 
----------- 
User ID 
Event ID 

Workers 
------- 
User ID 
Event ID

如果沒有其他的數據存儲與參與者和工人，你可以只使用一個表，並表示自己的狀態

SignUps 
------- 
EventID 
UserID 
Type (W | P)

你甚至可以做協調員這樣一來，萬一有過成爲（比知道它們的存在等）一個機會，一個事件有合作協調員

來源

2011-10-11 03:38:19

我認爲這是我想去的地方。我可以看到，這將會更容易理解，並且可能會更好地擴展。謝謝。 – Tim

enter image description here

來源

2011-10-11 12:15:49

我認爲這可能比我讀的第一個更有效。如果我錯了，請糾正我，但這更清楚地說明一個人是一個事件的協調員，另一個是另一個事件的參與者。 – Tim

@Tim，很好 - 簡化角色管理。更容易添加新的角色等。 –

卡在複雜的數據庫設計上

回答

相關問題