我有3種不同類型的用戶：數據庫ACL登錄設計
- 客戶端 -Employee -admin
，現在我只想要1的登錄頁面，以確定他們。
我的例子： 登錄表字段：
用戶名密碼ID的clientid adminid僱員角色
客戶表的字段：
名年齡地址標識。
現在我想添加一些用戶名：admin的客戶端。 我不能添加他，因爲像這樣的用戶名（與角色管理員）。客戶表僅用於額外的信息。最好的解決方案應該是1個表格，所有的信息，但我不需要的領域。例如：當我打印客戶信息時，我不需要現場工資（應爲可空），並且假設我有超過50個字段僅用於員工信息。我認爲我目前的數據庫設計很糟糕。我該怎麼辦？
有兩種思考方法。
一個是讓一個人和她可能採取的角色有所不同。這意味着人與角色之間的1：1，n關係。描述這個人的所有屬性，比如名字，用戶ID，哈希密碼，去到這個人，角色特定的屬性，比如薪水，去角色。如果真的發生一個人需要擔任多個角色，這是非常通用的。我不確定客戶和員工，但管理員和員工聽起來好像可以由同一個人一樣。
如果情況並非如此，即如果每個人都是客戶，員工或管理員，但從未超過其中一個，這將是矯枉過正的。那麼你邏輯上有一個繼承的情況，其中c，e和a是人的特例。在不支持繼承的關係數據庫中實現這個技術有多種。最簡單的方法是按照類的層次結構，這意味着將普通人和專業化的所有屬性放在一個表中，並在必要時讓它們爲空。如果每個專業化都有許多特定的屬性，則單獨的表格也是一種選擇。
順便說一下，所有這些與你是否只想要一個登錄頁面無關。即使你有多個表，你仍然可以將一個視圖定義爲它們的聯合，包含用戶名和哈希密碼以及可能的一些更常見的數據。
另外順便說一下，我在第一段中關於作爲人實體一部分的用戶憑證的評論是一種簡化。成爲用戶也可能是一個角色，甚至不一定與某個人綁定。想象一下需要訪問數據庫的一些自動作業。它也是一個用戶，可能會被分配一定的權限，但它不是人。我不知道你的要求是否使這種差異變得明智。