该加 student_id 字符串类型外键（用真实学号作 _id），不加 objectid；需建唯一索引防重复分配，删学生时手动批量删除关联记录，分配时用 findandmodify 抢锁。
宿舍分配表该不该加 student_id 外键约束？
不加，除非你确定所有操作都走应用层校验。MongoDB 本身不支持外键，硬加 $lookup 关联查或用应用逻辑模拟“外键”，反而让写入变慢、事务难保证。真实场景里，学生换宿舍频繁、退学/休学数据滞后，强一致性在这里是伪需求。
实操建议：
- 在
dorm_allocation集合里存student_id和dorm_id字符串字段，不建索引也行，但建议给student_id加唯一索引（防重复分配） - 删学生时，别依赖“级联删除”——MongoDB 没这功能。先查出该生所有
dorm_allocation记录，再批量deleteMany - 如果业务要求“分配即锁定床位”，得在应用层用
findAndModify或updateOne带{ upsert: true, returnDocument: 'before' }来抢锁，避免并发冲突
一个宿舍多个学生，dorm 集合该嵌数组还是独立 allocation 集合？
嵌数组看似省事，但宿舍调换、学生搬出、历史记录追溯全会崩。比如查“302 宿舍过去半年住过谁”，嵌在 dorm 文档里的数组只能存当前状态，没法回溯。
实操建议：
- 拆成两个集合：
dorms（存楼号、房间号、总床位数、设施等静态信息），dorm_allocations（每条记录代表一次入住/调宿/退宿事件） -
dorm_allocations必须含start_date和end_date（空值表示当前在住），方便按时间查、做重叠检测 - 查某宿舍当前住人：用
find({ dorm_id: "D302", end_date: null })，比从大文档里 $elemMatch 数组快得多，也利于分页和排序
aggregate 查“空床位”为什么总不准？
常见错误是只算 dorms.capacity - dorm_allocations.length，但没过滤掉 end_date 不为空的记录，把已退宿但没清理的数据也算进去了。
实操建议：
- 聚合必须包含
$lookup+$unwind+$match三步：先左关联dorm_allocations，再$unwind展开，再$match: { end_date: null }筛当前在住 - 别在聚合里用
$sum统计人数后跟$subtract算空位——MongoDB 4.4+ 支持$size，但更稳的是用$group+$sum: 1再$project计算差值 - 如果查询频次高，考虑用定时任务把空床位数预计算到
dorms文档的available_beds字段里，读快写慢的场景下这是合理妥协
为什么用 ObjectId 当 student_id 会出问题？
学生学号是业务主键，固定、可读、跨系统对账用。用 ObjectId 当 student_id，等于把数据库生成的随机 ID 暴露给前端、Excel 导出、教务系统对接——一旦要同步数据，对方根本认不出这个 62a1f8c9e4b0d51234abcd56 对应哪个学生。
实操建议：
-
students集合里必须用真实学号作_id（字符串类型），MongoDB 允许字符串当_id，且自带唯一+索引 - 所有关联集合（如
dorm_allocations）里的student_id字段，类型必须严格匹配——不能一半是字符串学号，一半是ObjectId，否则$lookup直接失效 - 插入前加一层校验：用正则
/^[A-Z]{2}\d{8}$/判断学号格式，比事后查错成本低得多
宿舍分配不是 CRUD 练习题，核心矛盾从来不是“怎么存”，而是“怎么让下次调宿、查历史、对教务数据时不翻车”。字段类型、时间语义、空值含义，这些细节漏一个，后期补救的代码量就是前期十倍。
