1 前言

在解决了科室和人员的基础管理后，我们面临一个新的问题：权限与职责的分配。

在医院里，同是“医生”，有的只是普通坐诊医生，有的是拥有审批权的“科主任”，还有的是负责全院调度的“医务处管理员”。如果仅仅依靠 t_personnel 表中的 type（医生/护士）字段，粒度远远不够。

我们需要引入 RBAC（Role-Based Access Control，基于角色的访问控制） 模型的核心概念：角色（Role）。

在传统开发中，实现 RBAC 通常需要三张表：用户表、角色表、用户角色关联表（User-Role）。但在低代码（微搭/云开发）中，为了保持**“模型服务于UI”的高效原则，我们继续沿用上一篇的扁平化**思路：不建中间表，直接在人员表里“挂”角色！

---

2 数据建模：轻量级设计

我们的目标是：在添加/编辑人员时，能够通过一个多选下拉框，直接给人员分配一个或多个角色（例如某人既是“心内科医生”，又是“工会组长”）。

2.1 新建角色表 (t_role)

首先，我们需要一个地方来定义有哪些角色。请登录 云开发平台 -> MySQL数据库，新建 t_role 表。

字段名称	字段标识	数据类型	必填	说明
角色名称	name	文本	是	如：科主任、护士长、系统管理员
角色标识	code	文本	是	唯一标识，用于代码逻辑判断，如 DEPT_HEAD
描述	desc	文本	否	备注说明

💡 经验之谈：code 字段非常重要！在后续写代码（如云函数或前端JS）判断权限时，我们应该判断 code == 'ADMIN'，而不是判断 name == '管理员'，因为名称可能会随时被修改。

2.2 修改人员表 (t_personnel)

这是实现“极简关联”的关键一步。我们不需要创建 t_personnel_role_rel 表，而是直接修改 t_personnel。

1. 找到 t_personnel 模型。
2. 添加字段：
   • 字段名称：所属角色
   • 字段标识：roles
   • 数据类型：关联关系
   • 关联模型：t_role (角色表)
   • 关联类型：多对多 (N:N)

⚡️ 高能预警：
为什么选“多对多”？因为一个人员可能身兼数职，一个角色也会包含多个人员。在微搭的表单组件中，“多对多”关联字段会自动渲染为“多选下拉框”，完美符合我们的需求！

---

3 页面搭建：配置即开发

接下来，我们需要两个页面：一个是角色管理（维护字典），一个是升级后的人员管理（分配角色）。

3.1 场景一：角色管理页面

这是一个标准的增删改查页面，用来维护系统中有哪些角色。

创建页面：新建“角色管理”页面。

删除网格布局，添加布局组件

添加数据表格组件

选择角色表，勾选场景

搞定！现在你可以去添加几个测试角色了，比如：“科室主任”、“普通医生”、“分诊护士”。

3.2 场景二：升级“人员管理”页面

回到我们上一篇做好的“人员管理”页面，我们需要让它支持角色分配。

第一步：升级列表展示

选择数据表格，添加列，选择所属角色，切换到自定义内容

添加标签组件

绑定标签的选项

第二步：升级编辑弹窗

找到之前做好的 “新增/编辑人员”弹窗，选中里面的 表单容器。

点击 “刷新数据模型” 图标，让表单感知到模型字段的变更。

在 字段管理 中，勾选 roles 字段。

自动渲染：你会发现表单里多了一个 “所属角色” 的表单项，且自动变成了一个支持搜索和多选的下拉框。

最终效果

在角色管理，可以添加、修改角色

在人员管理可以勾选角色

勾选了角色后在列表上可以展示

总结

通过在 t_personnel 中添加一个简单的多对多关联字段，我们只用了 5 分钟就实现了灵活的角色分配功能：

1. 模型扁平化：拒绝中间表，降低查询复杂度。
2. 组件自动化：利用微搭特性，自动生成多选组件和标签展示。
3. 逻辑解耦：角色标识 (code) 成为后续业务逻辑判断的锚点。

至此，我们的**医院基础数据建设（院区、科室、人员、角色）**已全部完成！

下一篇预告：
基础打牢，我们要开始攻克最核心的业务了——排班管理。如何设计一个既能按周循环，又能处理节假日调休的排班系统？这可是互联网医院的“心脏”！

关注我，带你用低代码复刻真实互联网项目！