在教务系统中，实验课的排课与设备分配涉及多表关联（课程表、设备表、预约表），请设计数据库表结构，并说明如何保证数据一致性（如避免重复预约、设备超负荷）。
答案
1) 【一句话结论】：核心是通过设计包含课程、设备、预约的多表关联结构，结合外键约束（保证数据关联）、唯一约束（防重复预约）、检查约束/事务机制（防设备超负荷），确保实验课排课与设备分配时数据一致性。
2) 【原理/概念讲解】：老师口吻，解释关系数据库的实体-关系模型。课程、设备是实体（表），预约是关联实体（表）。外键用于关联多表，保证参照完整性（如预约表中的course_id必须对应课程表的有效课程）。唯一约束用于预约表中的course_id、device_id、time_slot组合唯一，防止同一课程在同一设备同一时间重复预约。检查约束或事务中的逻辑判断用于设备超负荷检查（如设备在指定时间槽的预约数不超过其容量）。类比：课程表是“课程信息库”，设备表是“设备资源库”，预约表是“预约订单表”，订单需要同时从课程库和设备库“取货”，约束保证订单不重复（唯一），且设备库的可用容量足够（检查或事务锁）。
3) 【对比与适用场景】：
| 约束类型 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 主键 | 表中唯一标识记录 | 非空、唯一 | 表的唯一标识 | 不能为NULL |
| 外键 | 引用其他表主键 | 保证参照完整性 | 关联多表 | 目标表必须有主键 |
| 唯一约束 | 表中某列或组合唯一 | 非空（可空但唯一） | 防止重复数据 | 不强制非空 |
| 检查约束 | 限制列值范围 | 逻辑判断 | 验证数据有效性 | 部分数据库不支持动态值 |
| 事务 | 原子操作 | ACID（原子性、一致性、隔离性、持久性） | 并发操作保证一致性 | 需正确提交/回滚 |
4) 【示例】：设计表结构（伪SQL），确保设备容量非空，用具体例子。
-- 课程表
CREATE TABLE course (
course_id INT PRIMARY KEY,
course_name VARCHAR(50) NOT NULL,
credit INT NOT NULL
);
-- 设备表
CREATE TABLE device (
device_id INT PRIMARY KEY,
device_name VARCHAR(50) NOT NULL,
capacity INT NOT NULL, -- 设备最大容纳人数
type VARCHAR(20) -- 设备类型，如“显微镜”、“仪器室”
);
-- 预约表
CREATE TABLE reservation (
reservation_id INT PRIMARY KEY,
course_id INT NOT NULL,
device_id INT NOT NULL,
time_slot VARCHAR(20) NOT NULL, -- 如“2024-05-20 14:00-15:00”
student_id INT, -- 预约学生ID（可选）
FOREIGN KEY (course_id) REFERENCES course(course_id),
FOREIGN KEY (device_id) REFERENCES device(device_id),
UNIQUE (course_id, device_id, time_slot) -- 防止重复预约
);
检查设备超负荷的流程：插入预约前，先查询设备在时间槽的已预约数，若小于设备容量则插入，否则拒绝。用事务确保原子性，避免并发冲突。
事务中检查逻辑（伪代码）：
BEGIN TRANSACTION;
SELECT COUNT(*) INTO @used FROM reservation WHERE device_id = ? AND time_slot = ?;
IF @used < (SELECT capacity FROM device WHERE device_id = ?) THEN
INSERT INTO reservation (course_id, device_id, time_slot) VALUES (?, ?, ?);
ELSE
ROLLBACK;
END IF;
COMMIT;
5) 【面试口播版答案】：面试官您好，针对实验课排课与设备分配的多表关联问题，我设计如下数据库结构：首先创建课程表（course_id、课程名、学分）、设备表（device_id、设备名、容量、类型），核心是预约表，包含预约ID、课程ID、设备ID、时间槽，通过外键关联前两表。为保证数据一致性，首先用外键约束保证课程和设备的有效性（参照完整性），用唯一约束（course_id、device_id、time_slot组合唯一）避免重复预约。对于设备超负荷，通过事务中的检查逻辑，比如在插入预约前查询设备在指定时间槽的已预约数，若小于设备容量则允许插入，否则拒绝，这样既保证设备不会超负荷，又通过事务的原子性防止并发冲突。总结来说，通过多表关联的约束（外键、唯一、检查）和事务机制，有效解决了重复预约和设备超负荷问题。
6) 【追问清单】：
- 问：如何处理高并发下的预约冲突？
回答要点：采用乐观锁（版本号）或悲观锁（行级锁），比如乐观锁通过更新时检查版本号是否变化，避免重复提交；悲观锁在查询时加锁，确保同一时间只有一个事务操作。 - 问：如果设备容量动态变化，如何调整？
回答要点：在设备表中增加容量字段，当设备容量调整后，预约表中的检查约束会自动生效，无需修改预约逻辑。 - 问：如何优化预约表的查询性能？
回答要点：为course_id、device_id、time_slot字段建立索引，加速按课程、设备、时间槽的查询；对于频繁查询的设备，可建立覆盖索引。 - 问：如果需要记录预约学生的信息，如何扩展表结构？
回答要点：在预约表中增加student_id外键，关联学生表，同时可能需要增加学生表（student_id、姓名、学号），通过外键保证学生存在。
7) 【常见坑/雷区】：
- 忽略外键约束导致关联表数据不一致（如设备表删除设备后，预约表仍有引用）。
- 唯一约束设置错误，仅针对单字段，而需要多字段组合唯一，导致重复预约。
- 检查设备超负荷逻辑错误，仅检查设备总预约数，未考虑时间槽的并发（如设备在多个时间槽被预约，但总容量足够，但单个时间槽超负荷）。
- 忽略事务的隔离级别，导致并发下数据不一致（如脏读、不可重复读），应选择合适的隔离级别（如READ COMMITTED）。
- 设备表容量字段未设为非空，导致插入设备时遗漏容量，影响检查约束的判断。