员工表需支持组织变动，含manager_id、department_id、status；项目表需细化状态并记录关键时间戳；员工-项目关联表须支持多角色与工时；权限逻辑应通过视图封装而非sql硬编码。
员工表设计要支持组织架构变动
企业内部常有部门调整、汇报关系变更、岗位轮换，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 查项目成员时没过滤已退出人员，导致消息发错。