你的应用如何设计通讯录模型？
user.id，不需要感知用户背后的物理身份 person.id。通过这种设计，可以在保持业务身份清晰的同时，避免跨租户身份混淆，并为后续的组织同步、权限控制、成员管理等能力提供稳定的数据基础。person 表和 tenant 表即可。设计原则
1.
Person 表表示自然人，租户内身份由 User 表承载。2.
Department 表用于存储部门信息。3.
术语定义
| 术语 | 含义 |
|---|---|
| Person | 自然人或登录主体，用户的物理身份，全局唯一。石墨不需要感知用户的物理身份 |
| Tenant | 租户，表示一个企业或子公司 |
| User | 用户在租户内的身份。user.id 是和石墨交互的用户身份 id |
| Department | 租户内正式组织节点 |
| DepartmentUser | 用户与部门之间的任职关系 |
总体模型
Person 自然人表，即这个人的物理 身份是谁Tenant 租户表，承载了企业、子公司、事业群或 SaaS 客户的基础数据User 租户用户表自然人 Person 在租户中的身份Department 部门表，存储了租户下的部门数据DepartmentUser 部门用户表，存储了用户和部门的关联关系核心实体职责
Person
Person 表示物理身份或登录主体。不直接承载企业组织属性。建议仅保留稳定且跨租户复用的信息：Tenant
Tenant 表示某个租户。也是权限、配置、数据归属和审计边界。租户通常对应企业、子公司、事业群或 SaaS 空间。User
User 表示用户在某个租户中的身份。该层用于承载仅在租户范围内生效的信息，例如：User 是通讯录模型的核心枢纽。后续部门归属、和角色权限均建议挂在该层之上。Department
Department 表示某个租户下的部门。采用树形结构表达上下级部门关系。适用于：实体关系
组织模型
部门树
parent_id 作为基础关系字段，以方便进行上下级部门查询。成员模型
数据表建议
主实体
| 表名 | 说明 |
|---|---|
person | 用户物理身份信息 |
user | 用户的租户身份信息 |
tenant | 租户信息 |
department | 部门节点信息 |
关系实体
| 表名 | 说明 |
|---|---|
department_user | 用户与部门的关联关系 |
推荐表结构摘要
person
| 项 | 设计 |
|---|---|
| 主键 | id |
| 核心字段 | name、mobile、avatar_url、status |
| 唯一约束 | mobile |
| 说明 | 仅承载自然人稳定信息，不保存租户内组织关系 |
tenant
| 项 | 设计 |
|---|---|
| 主键 | id |
| 核心字段 | tenant_key、name、status |
| 唯一约束 | tenant_key |
| 说明 | 作为组织、成员、权限和配置的隔离边界 |
user
| 项 | 设计 |
|---|---|
| 主键 | id |
| 核心字段 | tenant_id、person_id、email、employee_no、display_name、title、member_type、member_status、joined_at、left_at |
| 唯一约束 | (tenant_id, person_id)、(tenant_id, employee_no) 可选 |
| 说明 | 作为租户内用户身份主表，后续关系统一挂接到该层 |
department
| 项 | 设计 |
|---|---|
| 主键 | id |
| 核心字段 | tenant_id、parent_id、name、code、path、sort、status |
| 唯一约束 | (tenant_id, code) |
| 说明 | 正式组织树主表，path 用于子树与祖先链查询 |
department_user
| 项 | 设计 |
|---|---|
| 主键 | id |
| 核心字段 | tenant_user_id、department_id、is_primary、job_title、manager_user_id、start_at、end_at、status |
| 唯一约束 | 有效期内单用户仅一个主部门 |
| 说明 | 承载主部门、兼职部门、任职称谓和汇报线 |
关系表设计视图
DepartmentUser 是用户和部门的关联表。关键字段建议
user
| 字段 | 说明 |
|---|---|
id | 唯一id |
tenant_id | 所属租户 |
persion_id | 对应自然人 ID |
employee_no | 工号 |
display_name | 租户内展示名 |
email | 用户在租户中使用的邮箱 |
title | 岗位或头衔 |
member_type | EMPLOYEE、CONTRACTOR、PARTNER、GUEST、EXTERNAL_CONTACT |
member_status | ACTIVE、INACTIVE、LEFT 等 |
joined_at | 入职时间 |
left_at | 离职时间 |
department
| 字段 | 说明 |
|---|---|
id | 唯一id |
parent_id | 父部门 |
code | 部门编码 |
path | 路径字段，用于快速祖先或子树查询 |
sort | 排序 |
status | 状态 |
department_user
| 字段 | 说明 |
|---|---|
id | 唯一id |
tenant_user_id | 租户用户 ID，即 user.id |
department_id | 部门 ID |
is_primary | 是否主部门 |
job_title | 任职名称 |
manager_user_id | 直接上级租户用户 ID |
start_at | 生效时间 |
end_at | 失效时间 |
status | 任职状态 |
关键约束
1.
user(tenant_id, person_id) 保持唯一。2.
3.
department、user 默认采用软删除，不直接物理删除。4.
5.
manager_user_id 必须指向同租户下的有效用户。6.
总结
1.
user 表为中心，连接用户的物理身份、租户和部门。2.
3.
@ 人和权限过滤场景。后续再按实际需要补充角色、同步任务、外部联系人等数据表。4.
person 表和 tenant 表，保留 user、department、department_user 三张表即可。修改于 2026-06-22 02:43:30