员工表设计要支持组织架构变动
企业内部常有部门调整、汇报关系变更、岗位轮换，
employee表不能只存静态信息。必须包含
manager_id（自关联到本表
id）、
department_id（外键到独立
department表）、
status（如
'active'/
'on_leave'/
'archived'），避免用字符串存部门名或上级姓名。
常见错误是把
manager_name直接作为字段——一旦该人离职或改名，数据就失效且无法追溯历史。正确做法是通过关联查最新快照，或另建
employee_history表记录职级/部门变更时间点。
示例关键字段：
CREATE TABLE employee (
id INT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(50) NOT NULL,
email VARCHAR(100) UNIQUE,
manager_id INT NULL,
department_id INT NOT NULL,
status ENUM('active', 'on_leave', 'archived') DEFAULT 'active',
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY (manager_id) REFERENCES employee(id),
FOREIGN KEY (department_id) REFERENCES department(id)
);
项目表需区分“立项”和“执行”状态
企业项目生命周期长，从立项审批、资源分配、阶段交付到结项审计，
project表的
status字段必须覆盖完整流程，不能只用
'open'/
'closed'两级。
推荐状态值：
'draft'（草稿）、
'approved'（已审批）、
'in_progress'（执行中）、
'on_hold'（暂停）、
'completed'（已交付）、
'closed'（已结项）。其中
'completed'和
'closed'必须分离——交付后可能还有财务对账、文档归档等动作，不能直接删数据或锁表。
容易被忽略的是时间维度：除
start_date和
end_date，还需
approved_at、
closed_at等明确时间戳字段，方便审计查询。
员工-项目关联必须支持多角色与工时记录
一个员工可在同一项目中担任多个角色（如“开发负责人”+“安全接口人”），且不同阶段投入工时不同。不能用单张
project_member表简单存
employee_id+
project_id。
正确结构应包含：
role字段（如
'pm',
'dev_lead',
'tester'），不依赖字典表，便于快速筛选
joined_at和
left_at，支持成员中途加入/退出 外键指向
timesheet或预留
hourly_rate字段，为后续成本分摊打基础
示例关联表：
CREATE TABLE project_assignment ( id INT PRIMARY KEY AUTO_INCREMENT, employee_id INT NOT NULL, project_id INT NOT NULL, role VARCHAR(30) NOT NULL, joined_at DATE NOT NULL, left_at DATE NULL, hourly_rate DECIMAL(8,2) NULL, FOREIGN KEY (employee_id) REFERENCES employee(id), FOREIGN KEY (project_id) REFERENCES project(id) );
避免在 SQL 层硬编码权限逻辑
很多团队习惯在查询里写
WHERE department_id = ?或
AND status != 'archived'控制可见范围，这会导致权限逻辑散落在各处，后期难维护。
更稳妥的做法是：
用视图（VIEW）封装常用权限过滤，例如
active_employee_in_dept视图自动排除
archived员工 应用层统一调用视图，而非直接查基表 敏感字段（如薪资、身份证号）单独建加密视图或用列级权限（MySQL 8.0+ 支持
CREATE COLUMN STATISTICS配合应用层解密）
硬编码的典型后果：HR 导出花名册时漏掉
on_leave员工；PM 查项目成员时没过滤已退出人员，导致消息发错。
