上级单位建一套系统给下面几个单位用，这种需求很常见。好处是统一标准、统一维护、省成本。真做起来，第一道门槛就是各单位的数据能不能互相看到。
这个问题的答案不同，系统的做法完全不一样，所以必须在设计之前定下来。
一、数据隔离的三种做法
第一种是各用各的库。每个单位一套独立的数据库和程序，物理上完全分开。这种隔离最彻底，单位之间不可能看到对方数据。缺点是维护成本高，升级一次要升好几套，数据汇总也要额外做。
第二种是一套程序加多套库。程序只有一份，每个单位连自己的库。隔离程度接近第一种，维护比第一种省一些，因为程序升级只需要升一份。缺点是多了一套库的连接管理。
第三种是一套程序加一套库，用单位标识区分。所有数据放在一张表里，每条记录打上所属单位的标记，程序里按标识过滤。这种最省资源，汇总统计最方便，但对程序的要求最高，任何一处查询忘了加过滤条件，就会出现越权看到别人数据的严重问题。
二、选哪种取决于两件事
第一件是单位之间有没有数据互通的需求。如果上级需要实时汇总各单位的业务数据做统计，那前两种做法都要额外开发数据上报或者汇总的机制，第三种天然就具备这个能力。
第二件是数据敏感程度。涉及个人隐私、案件信息、资金明细这类，隔离要求高，倾向于前两种。普通的业务管理类数据，第三种可以接受，只要程序写扎实。
实际项目里还有一种折中做法。基础数据，比如人员、单位、字典放在同一套库里共享。业务数据按第三种方式存放但加单位标识，并且对核心敏感表单独做物理隔离。这种混合方式能同时满足汇总需求和隔离要求，代价是结构复杂一些。
三、权限要分三层来定
第一层是单位内部。本单位的人只能操作本单位的数据，这是默认规则。需要注意同一个自然人可能同时属于多个单位，比如借调、兼职，系统要能处理这种一人多单位的情况。
第二层是跨单位查看。有的业务需要看下级单位的数据，比如上级管理部门查看各单位上报情况。这类权限单独配置，做成可以按单位授权的形式。
第三层是系统管理。谁负责维护单位信息、谁能新增单位、谁能调整跨单位权限，这类权限集中管理，不能分散。
四、几个容易被忽略的问题
各单位业务流程不一样怎么办。有的愿意统一，有的坚持按自己的来。建议在设计阶段做一次梳理，能统一的统一，统一不了的做成可配置的流程，让各单位自己选。全统一会让某些单位用不下去，全部可配置又等于没有标准。
单位的新增和停用怎么做。下属单位会有合并、撤销、新增的情况。系统要支持单位状态变更，停用之后该单位的数据要保留但不能新增，历史数据仍然可查。
还有数据归属的问题。系统是上级建的，但数据是各单位产生的。将来某个单位要调出数据或者不再使用这套系统，数据给不给、给多快，这些要提前约定，写进管理办法里，不能等到时候再谈。
上一篇没有了