希望大家建立表格时，都按以下建议做一个参考。
- CompanyID nvarchar 40 这个数据是哪个公司的
- [可省略]CompanyFullName nvarchar 40 公司的名称
- DepartmentID nvarchar 40 这个数据是哪个部门的
- [可省略]DepartmentFullName nvarchar 40 这个部门的名称
- StaffID nvarchar 40 这个数据是哪个员工的姓名
- [可省略]StaffFullName nvarchar 40 这个员工的姓名
当然以上表格的设计，主导思想。
1. 普通员工只能看自己的数据，不能看别人的数据，更不能修改别人数据了，
这时候，数据可以按 StaffID 进行过滤就可以了。
这时候，数据可以按 StaffID 进行过滤就可以了。
2. 部门主管可以看自己部门的数据，那可以用 DepaertmentID 进行过滤。
3. 公司的经理层，可以看自己公司的数据，那可以用 CompanyID 进行过滤。
以上当然是最简单的几个几个场景，还需要更复杂的情况，
例如 A只可以看 B、 C的数据，那就用 StaffID IN ('A', 'B') 类似来解决问题。
StaffID, 与 UserID 的区别，Staff 表示是这个公司的正式员工。
UserID 表示这个系统的用户，可能不是这个公司的职工，也可能是客户。
有些软件设计人员，设计程序时，想得有些不稳妥，例如，你会说 CompanyID、 DepartmentID 都可以通过
UserID 表示这个系统的用户，可能不是这个公司的职工，也可能是客户。
有些软件设计人员，设计程序时，想得有些不稳妥，例如，你会说 CompanyID、 DepartmentID 都可以通过
StaffID 可以计算得出，当然那些
FullName那些，也都可以通过以上的计算，能获得出数据，按这个思路来考虑
问题，的确数据有很多冗余了。
我们猜想一下，我以前在宁波东蓝科技工作，犹豫家里的原因，我工作1年多后，调动到杭州分公司工作了，我的
个人ID在同一个集团公司里，是没有变化的,但是我的公司已经变了，部门也变了，以前的数据是属于宁波公司，
而不是属于杭州公司的，而且人员的调动，公司之间的调动，部门之间的调动，甚至借用人员都是很普遍存在的问题。
还有，一个业务表里的数据很多，那要跟其他表进行关联才能获得其他数据，这时候，写SQL语句很烦恼，而且有时候
问题，的确数据有很多冗余了。
我们猜想一下，我以前在宁波东蓝科技工作，犹豫家里的原因，我工作1年多后，调动到杭州分公司工作了，我的
个人ID在同一个集团公司里，是没有变化的,但是我的公司已经变了，部门也变了，以前的数据是属于宁波公司，
而不是属于杭州公司的，而且人员的调动，公司之间的调动，部门之间的调动，甚至借用人员都是很普遍存在的问题。
还有，一个业务表里的数据很多，那要跟其他表进行关联才能获得其他数据，这时候，写SQL语句很烦恼，而且有时候
部门的名字，单位的名字也可能会有变化，以前的数据就是那个部门的叫那个名字时的数据，所以还是保留起来，也可以
写sql模糊查询等很方便，还有我们打个比方，我们整个集团的数据都存储在宁波，例如有统一的数据中心，在保管着
我们整个集团的组织架构、职员信息、权限分配、工作流程配置等，我们本地的业务数据库里是没有 部门、人员表的。
那这样的情况下，应该保存当时的部门职员的名字，还是比较合适的。
写sql模糊查询等很方便，还有我们打个比方，我们整个集团的数据都存储在宁波，例如有统一的数据中心，在保管着
我们整个集团的组织架构、职员信息、权限分配、工作流程配置等，我们本地的业务数据库里是没有 部门、人员表的。
那这样的情况下，应该保存当时的部门职员的名字，还是比较合适的。
将权限管理、工作流管理做到我能力的极致，一个人只能做好那么很少的几件事情。
本文转自 jirigala 51CTO博客，原文链接：http://blog.51cto.com/2347979/451734，如需转载请自行联系原作者
