上篇小项目之数据库设计经验分享 我分享了我同事设计的关于如何将数据结构不稳定的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并没有存储角色与功能之间的关系数据，它是借助程序来完成的，我们可以在配置文件中编写如下内容来确定特定角色仍有特有特定的功能。
<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代码生成器(续) 轻易帮助我们完成这些事情。