希望这些建议,能推动管理软件开发的规范化进程 (数据按权限过滤)

希望大家建立表格时，都按以下建议做一个参考。

1. CompanyID nvarchar 40 这个数据是哪个公司的
2. [可省略]CompanyFullName nvarchar 40 公司的名称
3. DepartmentID nvarchar 40 这个数据是哪个部门的
4. [可省略]DepartmentFullName nvarchar 40 这个部门的名称
5. StaffID nvarchar 40 这个数据是哪个员工的姓名 
6. [可省略]StaffFullName nvarchar 40 这个员工的姓名

当然以上表格的设计，主导思想。

1. 普通员工只能看自己的数据，不能看别人的数据，更不能修改别人数据了，
这时候，数据可以按 StaffID 进行过滤就可以了。

2. 部门主管可以看自己部门的数据，那可以用 DepaertmentID 进行过滤。

3. 公司的经理层，可以看自己公司的数据，那可以用 CompanyID 进行过滤。

以上当然是最简单的几个几个场景，还需要更复杂的情况，

例如 A只可以看 B、 C的数据，那就用 StaffID IN ('A', 'B') 类似来解决问题。
 

StaffID, 与 UserID 的区别，Staff 表示是这个公司的正式员工。
UserID  表示这个系统的用户，可能不是这个公司的职工，也可能是客户。

有些软件设计人员，设计程序时，想得有些不稳妥，例如，你会说CompanyID、DepartmentID 都可以通过

StaffID 可以计算得出，当然那些FullName那些，也都可以通过以上的计算，能获得出数据，按这个思路来考虑
问题，的确数据有很多冗余了。

我们猜想一下，我以前在宁波东蓝科技工作，犹豫家里的原因，我工作1年多后，调动到杭州分公司工作了，我的
个人ID在同一个集团公司里，是没有变化的,但是我的公司已经变了，部门也变了，以前的数据是属于宁波公司，
而不是属于杭州公司的，而且人员的调动，公司之间的调动，部门之间的调动，甚至借用人员都是很普遍存在的问题。

还有，一个业务表里的数据很多，那要跟其他表进行关联才能获得其他数据，这时候，写SQL语句很烦恼，而且有时候

部门的名字，单位的名字也可能会有变化，以前的数据就是那个部门的叫那个名字时的数据，所以还是保留起来，也可以
写sql模糊查询等很方便，还有我们打个比方，我们整个集团的数据都存储在宁波，例如有统一的数据中心，在保管着
我们整个集团的组织架构、职员信息、权限分配、工作流程配置等，我们本地的业务数据库里是没有 部门、人员表的。
那这样的情况下，应该保存当时的部门职员的名字，还是比较合适的。