0

我正在設計一個擁有多種用戶類型(即管理員,編輯,教師和學生)的數據庫。現在所有這些用戶都有一些共同的字段(CF)和一些與它們相關的唯一字段(UF)。我想知道這是不是一個好設計?數據庫設計問題:多種類型的用戶

表的用戶:[USER_ID(PK),CF1,CF2,...,CFN,USER_TYPE(枚舉)]

表管理:[ID(PK),UF_A1,UF_A2,...,U_AN ,USER_ID(FK)]

表編輯:[ID(PK),UF_E1,UF_E2,...,U_EN,USER_ID(FK)]

表教師:[ID(PK),UF_T1,UF_T2 ,...,U_TN,USER_ID(FK)]

表生:[ID(PK),UF_S1,UF_S2,...,U_SN,USER_ID(FK)]

其中UF_A,UF_E,UF_T和UF_S是每個相應表格的唯一字段。

現在我的問題是:

  1. 這是一個好的設計?如果不是,你將如何設計它?
  2. 如何確保user_type教師的用戶不在學生表中存儲例如?

PS:一些更多的積分,如果他們可能會在得到一個更好的瞭解有所幫助:

  1. 該數據庫將與笨使用。 CF的
  2. 的例子是:用戶名,密碼,電子郵件,個人資料圖片
  3. 獨特領域的
  4. 例子是:學生(年齡,報名號),教師(大學名,大學的標誌,學位。)
+0

10你會如何評價「好」? – 2013-05-08 09:40:27

+0

對不起,'好'不明確。我的意思是一個強大的,可擴展的設計,並遵循關係數據庫設計的最佳實踐。我之前沒有任何數據庫設計經驗,所以我很害怕做出一個可能在以後很昂貴的新手錯誤。 – joshi 2013-05-08 09:44:23

+0

我會選擇一個更「角色」的架構,所以SELECTS和JOINS不會變成噩夢。用戶表,角色表,user_role_vars表。 – jtavares 2013-05-08 15:05:45

回答

0

您的設計(Users.user_type)意味着某個人可以是管理員,或者該人員可以是編輯者,但不能同時爲兩者。這也意味着教師不能成爲編輯。這是你的意圖嗎?

Admin.user_id,Editors.user_id,Teachers.user_id,Students.user_id列通常是您所描述的結構類型中的主鍵。如果CodeIgniter不讓你讓它們成爲主鍵,你仍然需要聲明它們是唯一的。

獨特的領域的例子是。 。 。教師(大學名,大學標誌,學位)

這可能不是真的。

如何確保user_type教師的用戶不在學生表中存儲例如?

具有重疊約束,默認值,檢查約束和外鍵引用。它比聽起來容易。見this SO answer。但我不相信你真的想這樣做。

+0

非常感謝你!!!!!這非常有用,尤其是指向SO答案的指針。我認爲你指出的答案中顯示的那種設計正是我所期待的!非常感謝! – joshi 2013-05-08 13:08:19

0

您的設計說明了一種名爲的設計技術。
此標籤有一個信息選項卡,概述了該技術。

正如信息所說,還有一種可能有用的技術,即

1

您的設計是關係數據庫中繼承關係建模的3種公認方法之一;其他的是「每個類的類別」,其中每個子類都有自己的完整表格,或者「一個表格來統治它們全部」,其中所有可能的列都存在一個表格中。

其他備選方案使用Entity-Attribute-Value或文檔(例如JSON或XML)來存儲數據。

你的設計有以下好處:

  • 一致性:公共數據一致地存儲和管理;一旦你編寫了密碼規則,你就知道它們將被應用到任何地方。
  • 可維護性:很清楚哪些數據在哪裏存在,它允許您爲子類使用細微的不同實現(存儲教師名稱可能需要包括標題 - 「Dr.」,不能存儲學生姓名)。
  • 性能:在數據結構上運行關係查詢應該很快(「找到12到14個沒有註冊號的所有學生」);這對EAV或文檔解決方案可能會非常棘手。

缺點:

  • 創建一個新的子類可能需要創建一個新的表(這是EAV和文件解決方案經常贏)。
  • 跨子類查詢可能會比較棘手(「查找1990年以後出生的所有用戶或擁有斯坦福大學學位的用戶」)。這是「一張大桌子」經常贏的地方。
  • 某些關係不容易使用「標準」關係工具(如唯一鍵,外鍵等)進行建模 - 例如,「您既可以是學生也可以是老師,但不是兩個」。您可以改用觸發器或應用程序邏輯。
  • 多重繼承 - 例如,用戶可能既是編輯又是老師,可能會變得令人困惑。
+0

這是一個很好的答案。感謝指針和信息。 – joshi 2013-05-09 09:53:11