小項目之數據庫設計經驗分享2

      上篇小項目之數據庫設計經驗分享 我分享了我同事設計的關於如何將數據結構不穩定的excel數據導入到sql server數據庫，這篇呢，我來分享關於權限系統的問題。
     
      小項目的特點

      就是不能太復雜，下面的一些特點是不太適合小項目的,這里我認為的小項目的概念是指費用在10萬到100萬,周期1-6個月的項目，人員1-10,純屬個人意見。

      特點一：分層過多，不要一上來就拿一些某某大型系統的分層架構應用在小項目上，一個solution分N個解決方案文件夾，然后里面又有N個project。幾個月的項目，讓你的項目成員明白你的架構就夠費勁了，除非是做自己公司的產品，有大把時間花在培訓上，而且最重要的是，小項目不會有過於復雜的邏輯，沒有必要開着18米長的汽車上下班，奧拓也是可以的,而且簡單的項目分層也不能說明你的設計能力有多么的差。

      特點二：不及要為了解耦而過度設計,從而將項目的復雜度提升，項目本身業務點不多也不復雜，對解耦的需求不是那么強烈，所以就不要再在每個層上花時間應用Ioc了,不用並不代表你不會，也更不能代表你的項目就是失敗的項目。
     
      同樣道理，我們在選擇權限系統的方案時，也會存在上面的問題，很多系統對權限這塊要求並非那么強烈，夠用就行，所以下面的設計也不適合小項目：

      特點一：一想到應用權限系統就要在自己項目中應用一個多么復雜多么高深的設計，三四個月工期的項目，權限設計就要占一大半時間，值得嗎？
      特點二：不要輕易將自己的權限系統通用化，往往每個系統對權限的控制要求上都不太一樣，很難通用起來，與其花時間在這上面，還不如想想如何優化自己的系統來的更加實惠,我認為通用的只是設計思想，如何實現最好實際情況實際分析。
     
      我以前基本沒接觸過權限系統，因為基本沒做過管理類型的系統，最近有些項目需要用到權限控制，故進行了一番了解，下面是幾種比較常見的而且特別簡單易行的方案，還有些比較復雜點的我就不多說了。
     
      方案一：基於角色性的。
      這里列舉微軟的一個案例,membership的權限控制，在數據庫存儲方面，針對權限相關的，只有三個表:
      1:aspnet_Users,用於存儲用戶信息;
      2:aspnet_Roles，用於存儲角色信息;
      3:aspnet_UserInRoles，用於存儲用戶與角色之間的關系數據

     

      下面是數據庫表結構:

                          
      
      membership並沒有存儲角色與功能之間的關系數據，它是借助程序來完成的，我們可以在配置文件中編寫如下內容來確定特定角色仍有特有特定的功能。
     

            <location path= 
          " 
          ApplicationLog 
          " allowOverride= 
          " 
          true 
          "> 
          
    <system.web> 
          
      <authorization> 
          
        <allow roles= 
          " 
          Regional Admin 
          " /> 
          
        <deny users= 
          " 
          * 
          " /> 
          
      </authorization> 
          
    </system.web> 
          
  </location> 
         

 

      
      membership 權限控制缺點:
      缺點一:當功能特別多的時候，配置性信息會特別多。
      缺點二：不太容易維護權限控制，最直觀的就是修改配置文件,比起維護表數據要蹩腳一些。
      缺點三：Roles表擴展也是個問題，比如我們想讓Roles表增加一個國家的信息，除非我們完全重寫RoleProvider，沒有比較簡單易行的辦法。

      membership 權限控制的優點：
      優點一：系統自帶，不用自行開發。
      優點二：設計思路經典。
     
      方案二：基於操作性的。
      這里我簡單列下它的表結構：
      1：Users，同樣也是記錄用戶的信息。
      2：Actions，記錄所有的功能信息。
      3：UserInActions，記錄用戶與功能之間的關系數據。
      這種方案比起基於角色的控制，各有各的好處，需要根據實際項目的需求出發。

                             
      
       方案三：結合方案一以及方案二。
      上面兩種方案的特點是簡單易用，但還是不太靈活，控制的粒度不夠細。所以有了下面的合體結構。這個方案應付大多數系統的權限控制基本夠用了。

                             
       我們根據自身項目的特點在此基礎上做了一些調整或者叫做擴充吧：

       調整一：我們為Roles表以及Users表增加了國家的信息，不過這是數據方面的一種權限控制，為的是權限系統能夠支持多國家。

       調整二：我們細分了Actions表：

                  1：Actions，記錄大的功能信息，比如比賽信息，模板信息，人員信息；

                  2：SubActions,記錄大分類下的小功能信息，比如比賽信息下面，可分為查看，修改，刪除等。

       下圖是調整后的結構圖：

                                
      
         說明：

               由於公司沒有PowerDesigner,所以只能使用ERWin，總體感覺上沒有PowerDsigner好用，也許是我還沒學會的原因吧,下面是我遇到的一些問題：

               問題一：當為兩個表之間指定主外鍵關系時，如果兩個表的主鍵名稱相同時(比如上面每個表的主鍵都是Id)，就會發生沖突，我的解決方案就是先刪除子表的主鍵，但添加完關系后，系統會將主表的主鍵同時認定為子表的主鍵，最后我不得取消掉默認主鍵，然后重新創建主鍵。

               問題二：如果采用的是Indentifying relationship,那么系統會創建復合主鍵，即在子表中，會以子表自身主鍵以及新的外鍵共同構成復合主鍵,這個特點讓我感覺有點奇怪。

 

         總結：

              盡管第三種方案需要自己編寫權限方面的維護功能，比如角色的維護，功能表信息的維護，人員信息的維護，這里我們的項目由於采用的是Windows認證，故不會有人員注冊的功能，也不存在什么密碼相關的問題，所以基本來講無非就是對幾個表的CRUD操作，我可以利用最近修改的代碼生成器修改的T4代碼生成器(續) 輕易幫助我們完成這些事情。