今天給大家分享的是：用戶管理模塊
或者說用戶管理子系統如何設計，包括如何抽象以及相關的存儲。
大部分的應用中都會有用戶的概念，除非你的網站全部是匿名訪問，不保存用戶任何信息。其實這也是不好的，因為你的網站如果沒有用戶的概念，沒有設計用戶模塊，就很難收集用戶信息及用戶行為，也就很難有數據來分析用戶的喜好，也就少了一條給用戶提供更好服務的途徑。
現在是web2.0的時代，甚至是web3.0，用戶越來越在意網站給自己帶來的內容，顯示的內容是否合適自己，而且用戶很想參與網站的內容構建，想要對自己構建的內容進行聚合、管理。
說了這麼多，就是要說明用戶管理模塊很重要，是個應用就應該考慮，而且還是重中之重。
先來看一下用戶信息都包含哪些內容。
常見的內容包括：登錄賬號，登錄密碼，電子郵箱，個人網址，手機，QQ，簡介，標簽等等。
用戶還可能包括企業用戶，就會有：企業名稱，企業注冊號，企業工商號，企業營業執照號，法人，聯系人，聯系人職務等等企業信息。
如果是涉及到金錢往來的應用，例如：電商網站。肯定還會有銀行賬戶信息：開戶銀行名稱，開戶名稱，開戶賬號等。
用戶會有很多的類型。
有的是個人，有的是企業。
有的有銀行賬戶信息，有的沒有銀行賬戶信息，現在沒有的，以後可能會有。
在用戶認證方面現在可能是username/password，以後可能需要支持第三方認證（例如：微博，twitter，qq），還可能需要SSO。
單用戶模型，單表存儲模型
最開始想到的是就是一個用戶模型，然後把所有的屬性都建立在這個模型上，然後加上個用戶類型屬性區分一下。不同的用戶類型，使用不同的屬性。
在存儲方面就建立一張表，每個屬性來一個字段。雖然有很多的字段在一些情況下會有浪費，甚至在用戶量巨大的情況下，是非常浪費的。但是好處就是從模型到存儲，都是唯一的，來源唯一，省去一些獲取啊，類型轉換之類的麻煩。
但是也帶來另外的一些麻煩，就是在代碼中需要做很多的判斷。什麼類型，使用那些字段。
多用戶模型，多表存儲模型
上面的存儲太浪費了，而且不清晰，所有用戶都在一張表中，看起來有點不爽。
好吧，分開吧，根據用戶類型分開，每個用戶類型一個模型，單獨存儲一張表。
個人用戶：登陸賬號，登錄密碼，電子郵箱。
企業用戶：登陸賬號，登錄密碼，企業名稱，組織機構代碼，企業法人。
這下好像清晰了一點，需要什麼類型的用戶就用那個用戶的模型，就去那張表找。
但是有幾個問題：
1.登陸都是用username/password，在兩張表，難道寫兩遍，但是都一樣啊。好吧，也有解決辦法，那就是寫一個數據庫視圖，在視圖中連接兩張表，查詢視圖就可以了。這樣也解決了一些需要同時查詢所有用戶的場景，不錯。但是隨著用戶類型的增加，需要維護數據庫視圖，否則查詢結果就會產生誤差。但是查詢單個類型用戶的時候，是直接用表呢？還是用視圖呢？有點糾結了！
2.需要增加銀行賬戶信息，有幾類用戶需要添加，有的不需要添加。好吧，打開需要添加的表和模型，添加一下，但是有重復的工作量，是不是可以更好一點呢？
！！！
其實我有一點感悟，就是你的代碼寫的和業務越是貼近，它的復用性就會越低，就是和某種業務綁定了，甚至是和某一個業務點耦合了。
當然，有的時候會有這種需要，這段代碼就是為這個業務點來服務的。
但是有很多時候不是這樣的。
