社会结构组织化就决定了业务对象基于人还需要另外的一些人的集合的对象。
常用的就是公司、部门、职位
由于表所面对对象的抽象性程度不同，有些具体化的数据，比如公司结构某个岗位的人数统计字段，不适合放在抽象程度高的表中
Company表
| 字段 | 数据类型 | 作用 |
| CompanyName | 字符 | 公司名称 |
| CompanyLogo | 字符 | 公司logo地址 |
| CompanyAddress | 字符 | 公司注册地址 |
| CompanyWeb | 字符 | 公司网址 |
| Id | 整型 | 数据id |
| Status | 整型 | 数据状态 |
| CreateTime | 长高精度日期 | 数据创建时间 |
| CreateBy | 整型 | 创建人：人数据id |
| ModifyTime | 长高精度日期 | 数据修改时间 |
| ModifyBy | 整型 | 修改人：人数据id |
| IsDelete | 布尔 | 数据是否逻辑删除 |
Organization表
| 字段 | 数据类型 | 作用 |
| Name | 字符 | 组织结构名称 |
| Type | 整型 | 组织单位类型：部门、职位 |
| Introduction | 字符 | 组织单位介绍 |
| Id | 整型 | 数据id |
| Status | 整型 | 数据状态 |
| CreateTime | 长高精度日期 | 数据创建时间 |
| CreateBy | 整型 | 创建人：人数据id |
| ModifyTime | 长高精度日期 | 数据修改时间 |
| ModifyBy | 整型 | 修改人：人数据id |
| IsDelete | 布尔 | 数据是否逻辑删除 |
OrganizationRelation表
| 字段 | 数据类型 | 作用 |
| CompanyId | 整型 | 公司id |
| ParentId | 整型 | 上级id |
| OrganizationId | 整型 | 组织表数据id |
| Tatol | 整型 | 人数统计 |
| Id | 整型 | 数据id |
| Status | 整型 | 数据状态 |
| CreateTime | 长高精度日期 | 数据创建时间 |
| CreateBy | 整型 | 创建人：人数据id |
| ModifyTime | 长高精度日期 | 数据修改时间 |
| ModifyBy | 整型 | 修改人：人数据id |
| IsDelete | 布尔 | 数据是否逻辑删除 |
JobRelation表
| 字段 | 数据类型 | 作用 |
| PersonId | 整型 | 人员数据表id |
| OrganizationId | 整型 | 组织表数据id |
| Id | 整型 | 数据id |
| Status | 整型 | 数据状态 |
| CreateTime | 长高精度日期 | 数据创建时间 |
| CreateBy | 整型 | 创建人：人数据id |
| ModifyTime | 长高精度日期 | 数据修改时间 |
| ModifyBy | 整型 | 修改人：人数据id |
| IsDelete | 布尔 | 数据是否逻辑删除 |
此系列以技术积累一般（没有超级牛人）的组织为目标，数据量根本就不打算向阿里和企鹅的方向去想，设计目标够用就行，没成为GCC流传度软件那样的妄想。
所以，如果不是那种会害人产生经济损失或者技术上确实太丢人的bug，希望大家拿砖轻砸。版权声明：本文为博主原创文章，未经博主允许不得转载。