简介：面向数据库课程设计与Java GUI开发学习者，SQL Server人事管理系统项目完整覆盖从数据库建表到界面交互的全流程。压缩包内共197个文件，约18.06MB，含SQL建库脚本、18个Java源码、116个编译后的class文件、44张界面PNG图片、8个依赖JAR包，并附带设计报告docx与汇报PPT，便于复现系统、阅读代码和答辩展示。目前已有1403人学习下载。内容围绕员工、部门、职位等表结构设计，借助Swing界面实现员工信息添加、修改、删除、查询、薪资管理和岗位调动等典型功能；从Java源码可学习连接SQL Server完成数据增删改查的持久化写法，结合class文件与界面图片可还原运行效果，理解各模块之间的调用关系。报告与PPT还梳理了数据库建模过程、系统架构、实现难点和排错经验，能够帮助学习者减少课程设计中的踩坑时间，也为二次开发和其他人事类系统设计提供参考。
1. 为什么课程设计选它：人事管理系统与 SQL Server 的适配点
每年到了数据库课程设计开题的时候，我总会收到大量类似的私信：用什么题目既能体现数据库设计能力，又不容易在答辩时被问倒？我的建议一直很直接——SQL Server 数据库课程设计做人事管理系统。人事管理系统几乎覆盖了数据库原理教材里的全部核心考点：多表关联、主外键约束、视图、存储过程、触发器、索引和事务，业务逻辑足够真实，数据关系又不至于复杂到两个人做不完。相比图书管理系统和超市进销存，人事系统在业务上天然需要权限划分和敏感数据保护，这正好给设计者一个合理的理由去实现视图隔离、加密列和参数化查询，答辩时能讲的东西多出不少。本篇文章就按照我做课程设计辅导时最常用的方案，从建表、写存储过程到接通界面，把整套思路和踩过的坑完整过一遍。
人事系统的另一个优势是数据边界清晰，不需要纠结需求蔓延。员工、部门、职位、考勤和薪资这五个维度基本就是全部核心，课程设计文档里能写清楚的业务也就这么多。对新手来说，表少意味着外键关系更容易画清楚，E-R 图不会乱；对想冲高分的同学来说，在工资计算、部门统计报表和登录审计这几个点上有足够的纵深可以发挥。这篇实战笔记不做文档模板，目标只有一个——让你从零开始，把一套能查能改、有权限控制、有自动化逻辑的人事系统数据库端完整落地。
2. 三张核心表与完整性约束：把人事数据库的骨架搭对
2.1 表结构设计原则：按业务找实体，而不是按界面找输入框
很多第一次做课程设计的同学最容易犯的错，是照着界面的输入框去建表。登录界面有两个输入框就建一张 Users 表，员工表单有十几个字段就建一张 Employee 大表。这样做的结果往往是字段冗余、更新异常，答辩时老师问一句“这张表的冗余字段怎么消除”就答不上来。我的做法是先列业务实体，再定属性。人事管理系统的核心实体只有四个：员工、部门、职位、用户账号。考勤和薪资作为业务过程，各分一张表。也就是说，六张表起步，而不是一张大表搞定。
员工表是最关键的。设计时要把自然属性（姓名、性别、出生日期、身份证号）和业务属性（入职日期、部门编号、职位编号、工资编号）分开。身份证号用 CHAR(18) 而不是 VARCHAR，因为长度固定且不需要额外存储开销；性别建议用 CHECK 约束限定可取值，防止程序层绕过直接写脏数据。部门表和职位表相对简单，但注意部门表要加一个“状态”字段用于停用标记，删除操作在人事系统里应该用软删除，这个后面讲外键冲突时会展开。
2.2 建表语句：外键、默认值、检查约束一次性到位
以下是最小可运行版本的核心建表脚本。每位员工属于一个部门、一个职位，账号表与员工表保持一对一。
-- 部门表 CREATE TABLE Department ( DeptID INT IDENTITY(1,1) PRIMARY KEY, DeptName NVARCHAR(50) NOT NULL UNIQUE, ManagerID INT NULL, Status TINYINT NOT NULL DEFAULT 1, -- 1在职 0停用 CreateTime DATETIME NOT NULL DEFAULT GETDATE() ); -- 职位表 CREATE TABLE Position ( PosID INT IDENTITY(1,1) PRIMARY KEY, PosName NVARCHAR(50) NOT NULL, BaseSalary DECIMAL(10,2) NOT NULL CHECK (BaseSalary >= 0), Level TINYINT NOT NULL DEFAULT 1 ); -- 员工表 CREATE TABLE Employee ( EmpID INT IDENTITY(1,1) PRIMARY KEY, EmpNo CHAR(6) NOT NULL UNIQUE, -- 工号 固定6位 EmpName NVARCHAR(20) NOT NULL, Gender CHAR(1) NOT NULL CHECK (Gender IN ('M','F')), IDCard CHAR(18) NOT NULL UNIQUE, BirthDate DATE NULL, HireDate DATE NOT NULL, DeptID INT NOT NULL, PosID INT NOT NULL, Phone VARCHAR(20) NULL, Email VARCHAR(100) NULL, Status TINYINT NOT NULL DEFAULT 1, -- 1在职 0离职 CONSTRAINT FK_Emp_Dept FOREIGN KEY (DeptID) REFERENCES Department(DeptID), CONSTRAINT FK_Emp_Pos FOREIGN KEY (PosID) REFERENCES Position(PosID) ); -- 账号表 CREATE TABLE SysUser ( UserID INT IDENTITY(1,1) PRIMARY KEY, EmpID INT NOT NULL UNIQUE, LoginName VARCHAR(30) NOT NULL UNIQUE, LoginPwd VARBINARY(64) NOT NULL, -- 存哈希 不存明文 Role TINYINT NOT NULL DEFAULT 2, -- 1管理员 2普通员工 LastLoginTime DATETIME NULL, CONSTRAINT FK_User_Emp FOREIGN KEY (EmpID) REFERENCES Employee(EmpID) );逻辑说明：工号用 CHAR(6) 配合 UNIQUE 约束，保证业务标识稳定；身份证号加 UNIQUE 是因为它在业务上天然唯一，这个约束能挡住重复录入。LoginPwd 用 VARBINARY(64) 存的是哈希值而非原文，配合程序端用 SHA-256 加密后再落库，这是课程设计里比较少见但加分明显的细节。
参数说明：Department 表的 ManagerID 是指向 Employee 表的外键，但建表顺序决定了此时 Employee 还不存在，所以先留空不加约束，后续用 ALTER TABLE 补上。Status 字段统一用 TINYINT，0/1 可扩展，不要用 BIT——因为业务上可能出现“待审核”等中间状态。DECIMAL(10,2) 是工资字段的标准选型，不要用 FLOAT，浮点误差在工资计算里是致命的。
-- 补充部门经理外键 ALTER TABLE Department ADD CONSTRAINT FK_Dept_Mgr FOREIGN KEY (ManagerID) REFERENCES Employee(EmpID);这一步晚加的原因是表间存在循环引用：Department 引用 Employee，Employee 又引用 Department。SQL Server 允许这种设计，但建表时必须分两步走。如果怕循环引用导致级联删除混乱，可以在业务层面不允许删除有下属的部门，只做软删除。
2.3 必要但容易被忽视的索引与默认约束
很多同学建完表就急着写数据，直到数据量上了千行才发现查询变慢。课程设计的评审老师不一定会压测数据量，但索引设计往往是加分项。不管最终数据量多大，外键列一定要建索引，否则 JOIN 时 SQL Server 要反复做全表扫描。另外，工号、身份证号这类唯一键会自动生成索引，不用重复建。
CREATE INDEX IX_Employee_DeptID ON Employee(DeptID); CREATE INDEX IX_Employee_PosID ON Employee(PosID); CREATE INDEX IX_Employee_HireDate ON Employee(HireDate); -- 考勤表联合索引便于按员工+日期范围快速定位 CREATE INDEX IX_Attendance_EmpDate ON Attendance(EmpID, AttDate);注意点：联合索引的列顺序有讲究。把等值查询的列放在前面（EmpID），把范围查询的列放在后面（AttDate），这样 B 树可以同时服务两种查询模式。不要给 Gender、Status 这类低区分度列单独建索引，取值只有两三种，索引扫描反而比全表扫描更慢，这是新手最常踩的索引设计坑。
3. 存储过程、视图与触发器：让人事业务跑在数据库里
3.1 为什么业务逻辑要写在数据库层，而不是只写在应用层
做课程设计时有个常见的偷懒做法：所有业务判断都写在 C# 或 Java 的按钮事件里，数据库只负责存取数据。这个方案演示没问题，但答辩时遇到“如果多个客户端同时操作怎么办”就翻车了。把关键业务逻辑封装在存储过程里，等于把规则下推到数据库层，不管谁通过什么入口调用，都必须走同一套校验。同时，检查约束和触发器能兜住应用层漏掉的数据问题，三层防护比单层可靠得多。
我一般建议把员工新增、调动、离职和薪资计算四类业务写成存储过程。这四类操作都涉及多张表的联动修改，天然适合事务包裹。下面以“员工入职新增”为例，展示标准写法。
3.2 员工入职存储过程：事务、校验与输出参数
CREATE PROCEDURE usp_Emp_Add @EmpNo CHAR(6), @EmpName NVARCHAR(20), @Gender CHAR(1), @IDCard CHAR(18), @DeptID INT, @PosID INT, @HireDate DATE = NULL, @LoginName VARCHAR(30), @LoginPwd VARCHAR(64), -- 外部传入明文 存储前哈希 @Result INT OUTPUT, -- 0成功 1工号重复 2身份证重复 3部门不存在 @NewEmpID INT OUTPUT AS BEGIN SET NOCOUNT ON; SET @Result = 0; BEGIN TRY BEGIN TRANSACTION; -- 业务校验：使用 EXISTS 而非先 SELECT 再 INSERT，避免并发缝隙 IF EXISTS (SELECT 1 FROM Employee WHERE EmpNo = @EmpNo) BEGIN SET @Result = 1; ROLLBACK; RETURN; END; IF EXISTS (SELECT 1 FROM Employee WHERE IDCard = @IDCard) BEGIN SET @Result = 2; ROLLBACK; RETURN; END; IF NOT EXISTS (SELECT 1 FROM Department WHERE DeptID = @DeptID AND Status = 1) BEGIN SET @Result = 3; ROLLBACK; RETURN; END; INSERT INTO Employee(EmpNo, EmpName, Gender, IDCard, HireDate, DeptID, PosID) VALUES (@EmpNo, @EmpName, @Gender, @IDCard, ISNULL(@HireDate, GETDATE()), @DeptID, @PosID); SET @NewEmpID = SCOPE_IDENTITY(); -- 同步创建登录账号 INSERT INTO SysUser(EmpID, LoginName, LoginPwd, Role) VALUES (@NewEmpID, @LoginName, HASHBYTES('SHA2_256', @LoginPwd), 2); COMMIT TRANSACTION; END TRY BEGIN CATCH IF @@TRANCOUNT > 0 ROLLBACK; SET @Result = 4; -- 未知错误 END CATCH END;逻辑说明：整个新增操作浸泡在显式事务里，任何一步失败都能回滚，不会出现员工表加了数据但账号没建成的中间状态。EXISTS 比 SELECT COUNT(*) 更高效，因为只要命中一条就立刻返回。最后用 SCOPE_IDENTITY() 拿自增值，要注意它不是 @@IDENTITY——后者可能拿到触发器里生成的其它自增值。
参数说明：@HireDate 带默认 NULL，业务层可以不传，数据库自动用当天日期，也可以在建表时用 DEFAULT GETDATE() 进一步兜底。密码哈希用了 HASHBYTES('SHA2_256', ...)，返回的是 VARBINARY，所以 SysUser 表对应字段用 VARBINARY(64)。这是课程设计阶段性价比最高的账号保护方案。如果再讲究点，可以加盐，把每个用户独立的 Salt 列存储后拼接再哈希，但课程设计做到 SHA-256 已经能讲清楚安全思路了。
调用示例：
DECLARE @RC INT, @NewID INT; EXEC usp_Emp_Add '100001', N'张三', 'M', '110101199001011234', 1, 1, NULL, 'zhangsan', 'init123456', @RC OUTPUT, @NewID OUTPUT; SELECT @RC AS ResultCode, @NewID AS NewEmpID;3.3 视图与触发器：给答辩准备的两个亮点
视图最适合做“有选择的暴露”。在建表时存了身份证号、工资这类敏感列，但普通员工角色不应该能看到。创建一个只暴露基础信息的视图，再给账号表的角色配置不同的访问权限，比在应用层写 if 判断要专业得多。
CREATE VIEW vw_EmployeeBasic AS SELECT e.EmpID, e.EmpNo, e.EmpName, e.Gender, e.HireDate, d.DeptName, p.PosName FROM Employee e JOIN Department d ON e.DeptID = d.DeptID JOIN Position p ON e.PosID = p.PosID WHERE e.Status = 1;这个视图已经完成了三表 JOIN，只暴露非敏感列，应用层直接 SELECT * FROM vw_EmployeeBasic 就能拿到网格显示的数据，不需要再拼 JOIN。视图还有个隐藏优势：如果后续调整了表结构，只要保持视图输出列不变，前端代码可以完全不动。
触发器适合做自动化合规审计。比如员工离职是在 Employee 表做 UPDATE Status=0 而不是 DELETE，这时可以用触发器把离职记录写进审计表，留痕备查。
CREATE TABLE EmpAuditLog ( LogID INT IDENTITY PRIMARY KEY, EmpID INT NOT NULL, OldStatus TINYINT, NewStatus TINYINT, OperateTime DATETIME DEFAULT GETDATE() ); CREATE TRIGGER trg_Emp_StatusChange ON Employee AFTER UPDATE AS BEGIN SET NOCOUNT ON; IF UPDATE(Status) BEGIN INSERT INTO EmpAuditLog(EmpID, OldStatus, NewStatus) SELECT i.EmpID, d.Status, i.Status FROM inserted i JOIN deleted d ON i.EmpID = d.EmpID WHERE d.Status <> i.Status; END; END;逻辑说明：AFTER UPDATE 触发器里 inserted 和 deleted 两张虚拟表分别存新值和旧值，只有当 Status 发生变化才审计，避免无意义的日志膨胀。注意 UPDATE(Status) 判断的是“该列是否出现在 UPDATE 语句的 SET 子句中”，不是“值是否真的变了”，所以还要用 WHERE d.Status <> i.Status 过滤一次。这个细节很多文章不会写，答辩被追问时能答上来，印象分会明显不一样。
4. 用参数化查询把登录与员工维护界面接通
4.1 连接字符串与基础数据访问层写法
数据库设计得再好，最终要能跑通一个完整流程才算数。课程设计通常用 WinForms 或 WPF + ADO.NET，只要把数据库访问层写规范，数据库逻辑可以原封不动换成其它前端。连接字符串建议直接写在 App.config 里并且配置为可修改，方便答辩现场切换服务器。
<connectionStrings> <add name="HrDb" connectionString="Server=.;Database=HRSystem;Integrated Security=true;" providerName="System.Data.SqlClient" /> </connectionStrings>最小可用的数据访问层，不需要三层架构那么重，但至少要把连接创建和 SQL 执行封装起来：
public class DbHelper { private static string connStr = ConfigurationManager.ConnectionStrings["HrDb"].ConnectionString; private readonly SqlConnection _conn; public DbHelper() { _conn = new SqlConnection(connStr); } public DataTable ExecuteQuery(string sql, params SqlParameter[] parameters) { using var cmd = new SqlCommand(sql, _conn); if (parameters != null) cmd.Parameters.AddRange(parameters); var da = new SqlDataAdapter(cmd); var dt = new DataTable(); da.Fill(dt); return dt; } }逻辑说明：SqlParameter 数组是关键——所有外部输入都必须通过它传进去，禁止拼接 SQL 字符串。ADO.NET 的 SqlParameter 在 SQL Server 端是走 sp_executesql 的，除了防注入还有参数重用带来的执行计划复用效果。
参数说明：Integrated Security=true 说明用 Windows 身份验证，课程设计阶段连本地实例最省事。如果用 SQL Server 身份验证，要写成 User ID=sa;Password=xxx;，并且密码不要明文写在配置里。很多同学就是因为 sa 密码策略问题折腾防火墙，后面避坑章节会专门讲。
4.2 登录验证：哈希比对与权限落地
登录功能是每个评委都会亲自试的模块。写成参数化查询 + 哈希比对是最稳的：
public bool TryLogin(string loginName, string pwd, out DataRow userRow) { const string query = @" SELECT u.UserID, u.EmpID, u.Role, e.EmpName FROM SysUser u JOIN Employee e ON u.EmpID = e.EmpID WHERE u.LoginName = @Name AND u.Status = 1"; var dt = _db.ExecuteQuery(query, new SqlParameter("@Name", loginName)); if (dt.Rows.Count == 0) { userRow = null; return false; } // 从数据库取出哈希值 与入参哈希比对 const string hashQuery = "SELECT LoginPwd FROM SysUser WHERE LoginName = @Name"; var pwdBytes = DBHelper.ExecuteScalar(hashQuery, new SqlParameter("@Name", loginName)) as byte[]; var inputHash = System.Security.Cryptography.SHA256.Create() .ComputeHash(Encoding.UTF8.GetBytes(pwd)); if (pwdBytes != null && pwdBytes.SequenceEqual(inputHash)) { userRow = dt.Rows[0]; return true; } userRow = null; return false; }这里有个容易被忽略的点：先按用户名查出账号，再比对哈希，而不是把密码也拼进 WHERE 条件一次性查。原因是前者对“用户名不存在”和“密码错误”返回相同的失败结果，避免通过接口差异探测有效账号；同时拿到 Role 和 EmpName 后一次会话只需要查一次数据库，后面所有界面显示所需的上下文都有了。
4.3 员工列表查询与存储过程的调用封装
主界面上的员工列表一般要支持按姓名、部门、状态筛选。课程设计阶段用一条参数化查询就够了：
public DataTable SearchEmployees(string keyword, int? deptId, bool? activeOnly) { var sql = new StringBuilder(@" SELECT e.EmpNo, e.EmpName, e.Gender, e.HireDate, d.DeptName, p.PosName FROM vw_EmployeeBasic e LEFT JOIN Department d ON e.DeptID = d.DeptID LEFT JOIN Position p ON e.PosID = p.PosID WHERE 1=1 "); var parameters = new List<SqlParameter>(); if (!string.IsNullOrWhiteSpace(keyword)) { sql.Append("AND (e.EmpNo LIKE @kw OR e.EmpName LIKE @kw) "); parameters.Add(new SqlParameter("@kw", $"%{keyword}%")); } if (deptId.HasValue) { sql.Append("AND e.DeptID = @deptId "); parameters.Add(new SqlParameter("@deptId", deptId.Value)); } if (activeOnly == true) { sql.Append("AND e.Status = 1 "); } return DbHelper.ExecuteQuery(sql.ToString(), parameters.ToArray()); }这个写法解决了课程设计最常见的需求：多个筛选条件组合，条件不带时自动忽略。注意 LIKE 模糊查询的 % 拼接放在参数构造时，而不是拼到 SQL 文本里。这样既能走索引（如果建立了合适的索引且数据分布合理），也保持查询语句的参数化完整。
调用存储过程新增员工时，封装写法如下：
public int AddEmployee(string empNo, string empName, string gender, string idCard, int deptId, int posId, string loginName, string pwd) { using var cmd = new SqlCommand("usp_Emp_Add", _db.GetConnection()) { CommandType = CommandType.StoredProcedure }; cmd.Parameters.AddWithValue("@EmpNo", empNo); // ... 其余参数省略 var retVal = new SqlParameter("@Result", SqlDbType.Int) { Direction = ParameterDirection.Output }; cmd.Parameters.Add(retVal); var newId = new SqlParameter("@NewEmpID", SqlDbType.Int) { Direction = ParameterDirection.Output }; cmd.Parameters.Add(newId); cmd.ExecuteNonQuery(); return (int)retVal.Value; }注意 AddWithValue 是便捷写法，当传入的 C# 字符串长度明显小于数据库字段定义时，SQL Server 会推断为 NVARCHAR 但长度不匹配，可能影响索引使用。更严谨的做法是把类型和长度都显式声明为 SqlParameter。对于课程设计来说，AddWithValue 通常没问题，但如果你的数据量上万，建议改为显式参数类型。
5. 课程设计必踩的五个坑：从外键死锁到中文乱码
5.1 删除部门被外键拦截，界面直接报错
现象：部门管理里删除一个已有员工的部门，界面弹出“DELETE 语句与 REFERENCE 约束冲突”，程序崩溃。原因：Employee 表的 DeptID 外键引用 Department，有员工存在时删除必然失败。这其实是数据库在保护数据完整性，但课程设计的界面层往往没有做友好提示。
解决：方案分两层。数据库层不要对 DeptID 做级联删除——人事数据是历史数据，员工调动记录不能被抹掉。正确做法是先执行软删除：UPDATE Department SET Status = 0 WHERE DeptID = ...，保留记录但停用。应用层在删除前先做一次判断，调用存储过程或者执行 SELECT COUNT(*) FROM Employee WHERE DeptID = @id AND Status = 1，如果有在职员工则弹窗提示“部门存在在职员工，不允许停用”。把这两个判断都做上，答辩时能说清“为什么不直接 DELETE”，评分会上去。
5.2 SQL 注入不是玄学，是课程设计最容易丢分的安全项
现象：登录框输入' OR 1=1 --，居然跳过了密码验证直接进入主界面。原因：登录 SQL 直接拼接了用户输入的字符串，导致查询条件恒真。这是课程设计里最常见的翻车现场。
解决：所有用户输入一律走 SqlParameter 参数化查询，上面写的 DbHelper 已经封装好了。不要用字符串拼接的"SELECT ... WHERE UserName = '" + textBox.Text + "'"这种写法。如果想让答辩更有看点，可以在查询执行前加一层校验，比如长度超过 30 直接拒绝，然后解释这是纵深防御。
5.3 中文乱码：NVARCHAR 与 VARCHAR 的混用
现象：插入的员工姓名显示为问号或乱码。原因：某个中文相关的字段定义成了 VARCHAR，而没有用 NVARCHAR。SQL Server 的 VARCHAR 默认按数据库代码页存储，中文字符需要 N'...' 前缀或者使用 NVARCHAR 类型。
解决：凡是可能存中文的字段（姓名、部门名、职位名、备注）统一用 NVARCHAR，字符串常量前加 N 前缀。代码块里的N'张三'就是标准写法。同时，连接字符串里最好加上Character Set的对应设置。ADO.NET 连接 SQL Server 不需要额外字符集配置，但要确保 C# 文件本身以 UTF-8 编码保存，否则编译出来的字符串字面量天生就是乱码。这个坑比较隐蔽——数据库类型没问题、连接没问题，但 .cs 源文件编码错了，一样显示乱码。
5.4 本地能跑，换台电脑就连不上
现象：答辩前把数据库备份拷到教室电脑，连接字符串还是写Server=localhost，换机器后报“找不到服务器”。原因：连接字符串写死了服务器名，且备份还原方式不对。
解决：连接字符串用Server=.;Database=HRSystem;Integrated Security=true;，点号代表本机，换机器不用改。数据库还原用右键“还原数据库”而不是附加 MDF，比较稳妥。另外，把 SQL Server 的 TCP/IP 协议启用，避免某些环境默认关闭导致远程连接失败。更省心的方法是在 App.config 中把连接字符串做成可配置项，答辩现场用记事本改一行就能切换。
5.5 sa 密码登录被锁定，误以为是系统坏了
现象：用 SQL Server 身份验证登录，连续输入几次错误密码后，SA 账号被锁定，程序报“已锁定的登录”。原因：SQL Server 默认安全策略包含密码锁定阈值，连续失败会触发。
解决：先用 Windows 身份验证进入管理工具，找到该登录名，右键属性，在“状态”页里把“登录”设置为“启用”，在“常规”页重置密码。然后把“强制密码策略”勾选去掉。更稳妥的方案是全程用 Windows 身份验证 + 创建 Windows 账户映射，课程设计阶段完全够用，还省掉了密码管理的麻烦。如果要评价一下“哪个选择更稳”，我的答案是：在课程设计中直接用 Integrated Security，别去折腾 sa 密码。
6. 交付前最后一小时：用事务、索引与备份把成绩往上拉一档
结构化程度高的设计做完后，真正拉开差距的是收尾阶段的几个细节。第一个建议是给薪资表插入数据时，刻意用事务做一个批量更新演示：调整某个职位的薪资系数后，处理异常回滚。答辩时口头描述远不如当着老师面跑一次 SET XACT_ABORT ON，看到中途报错后数据没变，这个冲击力比任何截图都有说服力。
第二个建议是用 SQL Server Profiler 或者动态管理视图做一次索引使用统计，挑两个点讲：一个是 LIKE 查询在什么情况下走不到索引，另一个是为什么要避免在索引列上使用函数。比如WHERE YEAR(HireDate) = 2024会让 HireDate 的索引失效，改成WHERE HireDate >= '2024-01-01' AND HireDate < '2025-01-01'就能命中索引。这类细节一讲，基本可以确认你不是只背了建表语句。
第三个建议是主动做一次备份和还原演示。课程设计文档里写了“系统支持数据备份与恢复”，但答辩现场真能打开 SSMS 做一次完整备份并在另一台机器上还原成功的，比例相当低。把备份文件的路径设置到 D 盘而不是默认目录，说出为什么（C 盘空间有限、系统还原会清掉数据），这也是一个容易得分的细节。
我做过的模拟项目X里，有一次困在触发器死循环里排错到半夜。原因是两个表互相都加了 AFTER UPDATE 触发器，更新 A 触发 B，B 的触发器又回写 A，形成了无限循环。排查了很久才发现问题不是数据，也不在应用层，而是触发器逻辑设计缺陷。那之后我给自己定了个规矩：触发器里只做审计、日志和简单派生列计算，不做跨表回写；同时每条 UPDATE 语句都在触发器开头加一句IF @@ROWCOUNT = 0 RETURN，能省掉大量空触发器执行的开销。这条习惯一直在用，希望帮到你。
如果时间充裕，可以在程序里加一个“工资条查看”的只读视图页面，把基本工资、绩效、实发工资用视图计算好，前端只做展示。它是视图、计算列和权限控制三者的综合体，一个功能串起教材里三个重点，是收尾阶段性价比最高的一个模块。
本文还有配套的精品资源，点击获取
