- 数据层含91个业务实体，按资源、人员、分配、考勤、检查、治理六大类分组
- 18个幂等脚本对应每次结构变更，可重复执行，启动自动建库、迁移、序列同步
- 导入走模板、连接器、迁移工具三通道，质量规则先扫后落库
- 导出执行权限校验、内容快照与限流，字段清单和行数留痕可追
- 存储、传输、使用、导出四道安全防线，脱敏在展示层执行并入日志
明·如归 · 宿舍管理白皮书 ｜ 第九篇 全典篇
上一章"能做什么"。现在讲"它靠什么做"——数据实体、结构演进脚本、导入导出的完整链路。数据结构不是给程序员看的，是给治理者看的：一张表叫什么、装什么、谁在改、能不能追——这三个问题回答不清楚，就没法说"我们学校在管这件事"。
43.1 91 实体：按业务分组
系统的数据层由 91 个业务实体组成（表前缀统一为 app_），去重口径以数据上下文里声明的实体集为准。分成六大组：
- 资源类（约 8 个）：校区、楼、层、房间、床位、户型、设施模板、物资、收费标准。资源类的特点是"变动慢、审计要求高"——一间房从"四人间"改成"三人间"要留变更履历，不能只留最新状态。
- 人员与组织类（约 12 个）：学生、教师、账号、历史人员、组织六级树（学校→校区→学院→专业→班级→…）、用户组、角色、成员、应急联系人。人员类的核心是"归属双轨"——一个人既挂在教学组织上，也挂在宿舍维度上，两条不合并。
- 分配与变更类（约 14 个）：批次、分配记录、分配快照、床位状态、调宿申请、退住记录、走读、暂不考勤、假期分配。分配记录以"状态变更而非删除"为纪律——历史可查、责任可追。
- 考勤与请假类（约 15 个）：考勤日志、考勤来源、考勤状态、考勤日历、学期、调休、假日、请假申请、销假、审批链。考勤日志的每一次写入带来源、操作者、时刻、更新时刻四要素。
- 检查、评级与服务类（约 20 个）：卫生/文明/物品/违纪四类检查、宿舍积分、个人积分、星级、奖惩、报修工单、报修审批、设备台账、服务评价、评价模板。检查类记录"谁查的、什么时候、结果是什么、有没有整改"，评价类记录"给谁评的、分数、说明"。
- 治理、审计与配置类（约 22 个）：数据字典、字典标准列、字段元数据、消息、通知、订阅、开放接口客户端、操作日志、审计快照、定时任务、任务执行历史、问题工作台、质量规则、异常预警、地图配置、角色权限矩阵、菜单权限目录、数据同步策略、事件回调、事件回调 派发、站内警报、大屏配置、系统参数。
四档口径（对照能力全典的落地标注）：以上所有实体都是"已投产、当场可查"档——不写"规划中"、不写"部分支持"。
43.2 18 个幂等脚本：结构演进的完整履历
表结构不是一次性建完就永远不变的——新学期要加字段、评估要补台账、政策要理口径。每一次改动都写成一个幂等 结构化脚本，随程序发布：
| 覆盖能力 | 脚本 |
|---|---|
| 考勤与预警 | 归寝警报通知、假日与考勤日型 |
| 检查与评级 | 宿舍记录快照（历史留档）、日记明细数据 |
| 数据字典治理 | 字典标准列（统一枚举口径） |
| 其他 | 序列同步、性能索引、字段扩展…… |
18 个脚本按名字一一对应一次具体的结构变更。每一个脚本都可重复执行——"这个脚本再跑一次会不会炸"答案是"不会，因为已经存在的对象会被跳过"。幂等是治理的起点：不幂等的脚本意味着"每次上线都要盯着、失败要人回滚"，一旦运维换人，风险敞口立刻暴露。
启动时会自动做三件事：建库（不存在则创建，存在则跳过）→ 跑迁移脚本（每个脚本执行前查一次是否已经执行过）→ 序列同步（把 当前库 主键序列追平到当前最大 ID）。这三件事在每一次实例启动时都会跑——不管你是新装、重启、灾备恢复，都不需要人工干预。
43.3 导入导出全景
系统的每一次数据进出都是可审计的：
导入的三条通道：
- 模板导入：Excel 模板由字段元数据自动生成，字段增删时模板自动补齐——不写"要改模板请联系厂商"。
- 连接器同步：五类连接器（通用接口门禁、海康 ISAPI、OIDC、CAS、教务学籍）按各自协议拉取，落到暂存区后走四类对账报告（新增/更新/冲突/跳过）。
- 迁移工具：旧库到当前库 数据搬运，独立于运行时的应用，可反复演练。
导入的入口治理：错的数据要么当场拦下、要么进问题工作台——不允许"先塞进库里回头再清"。质量五规则（一人多占、性别不符、离校在住、证件校验位、通行无主）在数据落到正式表之前先扫一遍。
导出的三条纪律：
- 权限校验：谁在导、能导哪些范围（组织架构 + 宿舍维度双轨过滤）——导出跟查询走同一套权限。
- 内容快照：导出的字段清单和行数落到操作日志——事后能回答"他到底导了什么"。
- 限流：导入 5 次/分钟、登录 10 次/分钟；高频导出走异步任务队列，不阻塞交互。
43.4 数据安全的四道防线
数据层不是"存起来就完了"——敏感数据的存储、传输、使用、导出四道各有一件事要做：
- 存储：口令走 SHA256 + Salt；字段级加密按批次推进（当前仅覆盖最小必要项，扩面按投产前批次）。
- 传输：全链路 HTTPS；局域网 IP 上的移动打卡必须走受信任 HTTPS，微信与企业微信的安全来源限制不绕过。
- 使用：脱敏在展示层执行——身份证、手机号、家长联系方式默认打码；有权限者显式查看才还原；每一次"显式查看"入操作日志。
- 导出：字段清单和行数留痕；大批量走异步任务；带导出者身份和时刻。
四道防线之外还有 XSS 清洗、CSRF、Cookie 安全属性——这些不是宿舍业务的功能，是"配得上装学生住宿数据"的最低门槛。缺任何一样，都不能对外说"我们的数据是安全的"。
43.5 一张表能不能被改：字段元数据的分寸
一所学校用几年，一定会遇到"我要加一个字段"的诉求——是否少数民族预科、是否交换生、是否助学金户。传统做法是找厂商改程序、走一次发布；这套系统的做法是：字段元数据表（字段元数据表）支撑运行时增加字段。
- 加字段：管理员在字段字典里挂一条定义（实体、字段名、类型、必填、字典绑定、显示权限）→ 前端表单/列表/导入模板同步补齐 → 存储层通过迁移脚本添加物理列。
- 改字段：类型收窄要走迁移脚本、走数据回填、走审计——不是改一下配置就完了。
- 删字段：软删优先，保留历史数据可见；物理列删除要单独授权。
"改一个字段要不要找厂商改程序"是判断一套系统能不能长期可用的分水岭。字段元数据就是这条分水岭上的护栏。
43.6 治理台账：数据从"存在"到"可用"
有了实体、脚本、导入导出、安全四道防线，最后一步是"日常治理"：
- 问题工作台：质量扫描、对账冲突、归寝异常统一进这个台。每条问题有责任人、状态、处理时限、历史记录。治理不是"扫出来一次就完了"，是要有人认领、有状态可追、有历史可查。
- 定时任务执行历史：三个处理器（自动考勤、质量扫描、归寝异常）每天留一份执行记录——跑了多久、扫了多少条、生成多少问题、有没有失败。执行历史是治理系统的"值班表"。
- 字典治理工作台：所有枚举、状态码、分类字典集中管理，不允许散落硬编码。"改一个状态要重新发布"是数据治理不可接受的。
数据篇与全典篇在这里交汇：数据篇讲的是"为什么这样设计数据层"；这里讲的是"设计落地成了什么样的具体结构"。91 实体、18 脚本、三类导入通道、四条导出纪律、四道安全防线——每一个数字都能在系统里点开看到——这就是全典篇的意义。
下一章：智能化能力全典——三检测器、五规则、三定时任务、四 大模型 出口，每一项标注当前落地档，不吹不藏。