master/%E9%A1%B9%E7%9B%AE%E6%96%87%E6%A1%A3%E7%9B%B8%E5%85%B3/docs/%E5%91%98%E5%B7%A5%E9%97%A8%E5%BA%97%E5%BD%92%E5%B1%9E%E5%BF%AB%E7%85%A7%E8%A1%A8%E6%96%B9%E6%A1%88%E8%AF%A6%E7%BB%86%E8%AE%BE%E8%AE%A1.md

# 员工门店归属快照表方案详细设计
> **建表 SQL（与本文字段、索引对齐）**：`项目文档相关/sql/2026-4-3/R-002_员工门店归属快照表_lq_employee_store_assignment.sql`。合并版改造说明见 `用户主档与薪酬考勤改造记录.md`。
## 📋 方案概述
通过创建门店归属快照表，记录员工每个月的门店归属历史，以时间维度为唯一标准，解决工资计算和数据补录中的门店归属问题。
---
## 🗄️ 数据模型设计
### 1. 核心表设计
#### 表名：`lq_employee_store_assignment`（员工门店归属表）
#### 字段设计
| 字段名               | 类型           | 说明     | 约束          | 备注                |
| ----------------- | ------------ | ------ | ----------- | ----------------- |
| F_Id              | VARCHAR(50)  | 主键ID   | PRIMARY KEY | 使用YitIdHelper生成   |
| F_EmployeeId      | VARCHAR(50)  | 员工ID   | NOT NULL    | 关联BASE_USER.F_Id  |
| F_StoreId         | VARCHAR(50)  | 门店ID   | NOT NULL    | 关联lq_mdxx.F_Id    |
| F_StoreName       | VARCHAR(200) | 门店名称   |             | 冗余字段，便于查询和显示      |
| F_Year            | INT          | 年份     | NOT NULL    | 如：2025            |
| F_Month           | INT          | 月份     | NOT NULL    | 1-12              |
| F_StatisticsMonth | VARCHAR(6)   | 统计月份   | NOT NULL    | YYYYMM格式，如：202501 |
| F_StartDate       | DATE         | 归属开始日期 | NOT NULL    | 精确到天，用于月中调店       |
| F_EndDate         | DATE         | 归属结束日期 | NULL        | 为空表示当前仍在归属，精确到天   |
| F_CreateTime      | DATETIME     | 创建时间   |             |                   |
| F_UpdateTime      | DATETIME     | 更新时间   |             |                   |
| F_CreateUser      | VARCHAR(50)  | 创建人    |             |                   |
| F_UpdateUser      | VARCHAR(50)  | 更新人    |             |                   |
| F_IsEffective     | INT          | 是否有效   | DEFAULT 1   | 1=有效，0=无效（软删除）    |
| F_Remark          | VARCHAR(500) | 备注     |             | 记录调店原因等           |
#### 索引设计
```sql
-- 主键索引（自动创建）
PRIMARY KEY (F_Id)
-- 员工+月份查询索引（最常用）
INDEX idx_employee_month (F_EmployeeId, F_StatisticsMonth, F_IsEffective)
-- 门店+月份查询索引（用于门店维度统计）
INDEX idx_store_month (F_StoreId, F_StatisticsMonth, F_IsEffective)
-- 日期范围查询索引（用于精确查询某天的归属）
INDEX idx_employee_date (F_EmployeeId, F_StartDate, F_EndDate)
-- 时间范围查询索引（用于查询某个时间点的归属）
INDEX idx_date_range (F_StartDate, F_EndDate, F_IsEffective)
```
#### 唯一约束
**重要考虑：是否允许一个员工在一个月内归属多个门店？**
**建议：允许**（支持月中调店场景）
**唯一约束设计：**
- 不设置唯一约束（允许一个员工一个月有多条记录）
- 通过业务逻辑保证：同一个员工的同一天只能有一条有效记录
- 通过应用层校验：插入/更新时检查是否有日期重叠
---
### 2. 数据关系图
```
BASE_USER (员工表)
    ↓ F_Id
lq_employee_store_assignment (门店归属表)
    ↓ F_StoreId
lq_mdxx (门店表)
    ↓
lq_salary_statistics (工资统计表) - 使用归属表的门店信息
lq_kd_jksyj (开单业绩表) - 使用归属表的门店信息
lq_xh_jksyj (消耗业绩表) - 使用归属表的门店信息
```
---
## 📐 业务规则设计
### 1. 基础规则
#### 1.1 时间维度原则
- **唯一标准**：以数据实际发生的时间（年、月、日）作为门店归属的判断标准
- **不可变更**：历史归属记录一旦创建，原则上不允许修改（可通过软删除+新增的方式调整）
#### 1.2 归属记录创建规则
**场景A：月初调店（整月归属一个门店）**
- 员工在1月1日从门店A调到门店B
- 创建两条记录：
  - 记录1：1月，门店A，开始日期：1月1日，结束日期：1月1日（或空，如果跨月）
  - 记录2：1月，门店B，开始日期：1月2日，结束日期：空（或1月31日）
**场景B：月中调店（一个月归属两个门店）**
- 员工在1月15日从门店A调到门店B
- 创建两条记录：
  - 记录1：1月，门店A，开始日期：1月1日，结束日期：1月14日
  - 记录2：1月，门店B，开始日期：1月15日，结束日期：1月31日（或空）
**场景C：整月归属一个门店**
- 员工整个月都在门店A
- 创建一条记录：
  - 记录：1月，门店A，开始日期：1月1日，结束日期：1月31日（或空）
#### 1.3 归属记录查询规则
**查询某员工某月的所有门店归属：**
```sql
SELECT * FROM lq_employee_store_assignment
WHERE F_EmployeeId = @EmployeeId
  AND F_StatisticsMonth = @StatisticsMonth
  AND F_IsEffective = 1
ORDER BY F_StartDate
```
**查询某员工某天的门店归属：**
```sql
SELECT * FROM lq_employee_store_assignment
WHERE F_EmployeeId = @EmployeeId
  AND F_StartDate <= @Date
  AND (F_EndDate >= @Date OR F_EndDate IS NULL)
  AND F_IsEffective = 1
ORDER BY F_StartDate DESC
LIMIT 1
```
**查询某门店某月的所有员工：**
```sql
SELECT DISTINCT F_EmployeeId FROM lq_employee_store_assignment
WHERE F_StoreId = @StoreId
  AND F_StatisticsMonth = @StatisticsMonth
  AND F_IsEffective = 1
```
### 2. 数据维护规则
#### 2.1 自动维护机制
**触发时机：员工调店时**
**操作步骤：**
1. 用户在前端操作：员工从门店A调到门店B（选择调店日期）
2. 后端处理逻辑：
  - 查询当前员工的有效归属记录（结束日期为空的记录）
  - 如果存在，将结束日期设置为调店日期的前一天
  - 创建新的归属记录：开始日期为调店日期，结束日期为空
  - 如果调店日期是月初，更新统计月份；如果是月中，保持原月份，新增记录
#### 2.2 手动维护机制
**适用场景：**
- 历史数据补录
- 数据修正
- 批量导入
**操作方式：**
- 提供管理界面：员工门店归属管理
- 支持批量导入Excel
- 支持手动添加/编辑/删除（软删除）
#### 2.3 数据校验规则
**插入/更新时的校验：**
1. **日期范围校验**：
  - 开始日期不能大于结束日期
  - 开始日期和结束日期必须在同一个月内（或跨月但统计月份相同）
2. **重叠校验**：
  - 同一个员工，同一天不能有多条有效记录
  - 如果存在重叠，需要先处理旧记录（结束或删除）
3. **完整性校验**：
  - 员工ID、门店ID必须存在
  - 统计月份格式正确（YYYYMM）
4. **业务逻辑校验**：
  - 门店必须有效（未删除）
  - 员工必须有效（未删除、已启用）
---
## 🔄 与现有系统集成
### 1. 工资计算集成
#### 1.1 健康师工资计算
**当前逻辑：**
```csharp
// 1. 优先从业绩数据中获取门店（performanceData中的StoreId）
// 2. 如果没有，从消耗数据中获取门店
// 3. 如果还没有，使用 BASE_USER.F_Mdid
```
**调整后逻辑：**
```csharp
// 1. 查询门店归属快照表（按统计月份）
var storeAssignments = await QueryStoreAssignment(employeeId, statisticsMonth);
// 2. 如果快照表有记录，使用快照表的门店归属
if (storeAssignments.Any())
{
    // 按时间范围拆分计算（如果一个月有多个门店）
    foreach (var assignment in storeAssignments)
    {
        // 查询该员工在该门店、该时间范围内的业绩数据
        // 计算该部分工资
    }
}
// 3. 如果快照表没有记录，使用当前逻辑（回退方案）
else
{
    // 使用现有逻辑：从业务数据或BASE_USER获取
}
```
**特殊处理：月中调店**
- 如果一个月有多个门店归属，需要按时间范围拆分计算
- 每个时间段的业绩数据单独统计
- 工资计算结果需要合并（一个员工一个月可能有多条工资记录？还是合并为一条？）
**建议：合并为一条记录**
- 工资统计表仍然是一个员工一个月一条记录
- 但需要记录主要门店（归属时间最长的门店，或业绩最多的门店）
#### 1.2 其他岗位工资计算
**店长工资：**
- 店长通常是固定门店，但也要支持调店
- 计算逻辑与健康师类似
**主任工资：**
- 类似逻辑
**其他岗位：**
- 统一使用快照表逻辑
### 2. 数据补录集成
#### 2.1 开单数据补录
**当前问题：**
- 补录历史数据时，如果没有门店信息，可能使用当前门店（BASE_USER.F_Mdid）
**调整后逻辑：**
```csharp
// 补录开单数据时
public async Task ImportBillingData(BillingRecord record)
{
    var billingDate = record.BillingDate; // 开单日期
    var employeeId = record.EmployeeId;   // 健康师ID
    var statisticsMonth = $"{billingDate.Year}{billingDate.Month:D2}";
    
    // 1. 查询该日期该员工的门店归属
    var assignment = await QueryStoreAssignmentByDate(employeeId, billingDate);
    
    // 2. 设置门店ID
    if (assignment != null)
    {
        record.StoreId = assignment.StoreId;
    }
    else
    {
        // 回退方案：使用当前逻辑
        record.StoreId = GetStoreIdByCurrentLogic(employeeId);
        
        // 可选：记录警告日志，提示需要维护门店归属
        _logger.LogWarning($"员工{employeeId}在{billingDate}的门店归属未找到，使用当前门店");
    }
    
    // 3. 保存数据
    await SaveBillingRecord(record);
}
```
#### 2.2 消耗数据补录
**类似逻辑：**
- 根据消耗日期（Yjsj）查询门店归属
- 设置消耗记录的StoreId
### 3. 数据查询集成
#### 3.1 员工列表查询
**当前逻辑：**
- 直接从BASE_USER表查询，显示F_Mdid对应的门店
**调整后逻辑：**
- 如果要显示历史门店，需要关联查询快照表
- 当前门店：BASE_USER.F_Mdid（实时）
- 历史门店：从快照表查询
#### 3.2 门店员工列表查询
**场景：查询某门店某月的所有员工**
**当前逻辑：**
- 查询BASE_USER表，F_Mdid = 门店ID
**调整后逻辑：**
```sql
-- 查询某门店某月的所有员工
SELECT DISTINCT esa.F_EmployeeId, u.F_RealName
FROM lq_employee_store_assignment esa
INNER JOIN BASE_USER u ON esa.F_EmployeeId = u.F_Id
WHERE esa.F_StoreId = @StoreId
  AND esa.F_StatisticsMonth = @StatisticsMonth
  AND esa.F_IsEffective = 1
  AND u.F_DeleteMark IS NULL
  AND u.F_EnabledMark = 1
```
---
## 📊 数据迁移策略
### 1. 历史数据来源
#### 1.1 数据来源分析
**可能的数据来源：**
1. **工资统计表（lq_salary_statistics等）**
  - 已有历史工资记录
  - 工资记录中有门店ID（F_StoreId）
  - 可以反向推导：员工+月份 → 门店
2. **业务数据（开单/消耗表）**
  - 开单业绩表（lq_kd_jksyj）有门店ID（F_StoreId）
  - 消耗表（lq_xh_jksyj）有门店ID（F_StoreId）
  - 可以统计：员工+月份 → 门店（取出现最多的门店）
3. **BASE_USER表的变更日志（如果有）**
  - 如果系统有记录用户表变更日志，可以追溯
4. **人工确认**
  - 对于无法确定的数据，需要人工确认
#### 1.2 数据迁移优先级
**优先级1：工资统计表（最可靠）**
- 理由：工资记录是最终结果，门店归属相对准确
- 方法：从工资统计表提取：员工ID + 统计月份 + 门店ID
- 时间范围：最近2年的数据（或更长时间，根据业务需要）
**优先级2：业务数据统计（补充）**
- 理由：对于没有工资记录的月份，从业务数据推断
- 方法：统计每个员工每个月的业绩数据，取门店出现最多的
- 注意：可能存在一个月有多个门店的情况（月中调店）
**优先级3：BASE_USER当前门店（兜底）**
- 理由：对于完全没有数据的员工，使用当前门店
- 方法：BASE_USER.F_Mdid作为最后兜底
### 2. 数据迁移步骤
#### 步骤1：数据提取
```sql
-- 从工资统计表提取（健康师工资）
INSERT INTO lq_employee_store_assignment 
(F_Id, F_EmployeeId, F_StoreId, F_StoreName, F_Year, F_Month, F_StatisticsMonth, F_StartDate, F_EndDate, ...)
SELECT 
    YitIdHelper.NextId(),
    F_EmployeeId,
    F_StoreId,
    (SELECT F_Dm FROM lq_mdxx WHERE F_Id = F_StoreId),
    YEAR(STR_TO_DATE(CONCAT(F_StatisticsMonth, '01'), '%Y%m%d')),
    MONTH(STR_TO_DATE(CONCAT(F_StatisticsMonth, '01'), '%Y%m%d')),
    F_StatisticsMonth,
    STR_TO_DATE(CONCAT(F_StatisticsMonth, '01'), '%Y%m%d'), -- 开始日期：月初
    LAST_DAY(STR_TO_DATE(CONCAT(F_StatisticsMonth, '01'), '%Y%m%d')), -- 结束日期：月末
    NOW(),
    NOW(),
    'System',
    'System',
    1
FROM lq_salary_statistics
WHERE F_StoreId IS NOT NULL AND F_StoreId != ''
GROUP BY F_EmployeeId, F_StatisticsMonth, F_StoreId
```
#### 步骤2：数据清洗
**处理重复记录：**
- 如果一个员工一个月有多条记录（可能是数据异常，也可能是月中调店）
- 需要人工确认：是数据异常还是确实调店
**处理缺失数据：**
- 对于没有工资记录但可能有业务数据的员工
- 从业务数据统计推断
#### 步骤3：数据验证
**验证规则：**
1. 每个员工每个月至少有一条记录（如果有业务数据）
2. 门店ID必须存在
3. 统计月份格式正确
4. 日期范围合理
**验证方法：**
- 抽样检查：随机抽取一定比例的数据，人工验证
- 逻辑检查：检查是否有明显异常（如同一员工同一天多个门店）
#### 步骤4：数据导入
**导入方式：**
- 批量导入（使用事务保证一致性）
- 分批次导入（避免锁表时间过长）
- 记录导入日志（成功/失败记录）
### 3. 数据迁移时间窗口
**建议：**
- 选择业务低峰期（如夜间或周末）
- 分批次迁移（先迁移最近3个月，验证无误后再迁移更多）
- 保留回滚方案（如果迁移失败，可以删除导入的数据）
---
## 🎯 边界情况处理
### 1. 月中调店
**场景：** 员工在1月15日从门店A调到门店B
**处理方案：**
- 创建两条归属记录
- 工资计算时，按时间范围拆分计算
- 最终工资记录合并为一条（记录主要门店）
**问题：**
- 工资统计表中的门店ID如何设置？
  - 方案A：设置为主要门店（归属时间最长的门店，或业绩最多的门店）
  - 方案B：设置为空，或记录为"多门店"
  - **建议：方案A**，记录为主要门店，在备注或明细中说明
### 2. 数据缺失
**场景：** 快照表中没有某员工某月的归属记录
**处理方案：**
- 回退到现有逻辑（从业务数据或BASE_USER获取）
- 记录警告日志，提示需要维护门店归属
- 可选：自动创建一条归属记录（使用当前门店或推断的门店）
### 3. 数据冲突
**场景：** 同一个员工同一天有多条归属记录（数据异常）
**处理方案：**
- 数据校验时发现冲突，不允许插入/更新
- 提示用户先处理冲突记录
- 提供数据修正工具
### 4. 跨月调店
**场景：** 员工在1月31日调到门店B，实际在2月1日生效
**处理方案：**
- 记录1月：门店A，结束日期：1月31日
- 记录2月：门店B，开始日期：2月1日
- 如果调店日期是月末最后一天，可以考虑归属到下个月
### 5. 离职员工
**场景：** 员工在月中离职
**处理方案：**
- 创建归属记录：结束日期设置为离职日期
- 如果离职日期是月中，归属记录只到离职日期
- 工资计算时，只计算到离职日期
### 6. 新员工入职
**场景：** 新员工在月中入职
**处理方案：**
- 创建归属记录：开始日期为入职日期
- 如果入职日期是月中，从入职日期开始归属
---
## ⚡ 性能考虑
### 1. 查询性能优化
#### 1.1 索引优化
- 已设计多个索引（见索引设计部分）
- 定期分析索引使用情况，优化索引
#### 1.2 查询优化
**批量查询：**
- 工资计算时，批量查询所有员工的归属记录，避免N+1查询
```csharp
// 批量查询
var employeeIds = salaryList.Select(s => s.EmployeeId).Distinct().ToList();
var assignments = await _db.Queryable<EmployeeStoreAssignmentEntity>()
    .Where(x => employeeIds.Contains(x.EmployeeId) && x.StatisticsMonth == monthStr)
    .ToListAsync();
var assignmentDict = assignments.GroupBy(x => x.EmployeeId).ToDictionary(g => g.Key, g => g.ToList());
```
**缓存策略：**
- 对于频繁查询的数据（如当前月的归属记录），可以使用缓存
- 缓存失效策略：归属记录更新时，清除相关缓存
### 2. 写入性能优化
#### 2.1 批量插入
- 数据迁移时，使用批量插入（如每次插入1000条）
- 使用事务保证一致性
#### 2.2 异步处理
- 数据迁移可以异步处理
- 员工调店时，归属记录的创建可以异步处理（如果对实时性要求不高）
### 3. 表分区考虑
**是否需要分区？**
- 如果数据量很大（如10年历史数据，每月几千员工），可以考虑按年份或月份分区
- 当前阶段可能不需要，但设计时要考虑扩展性
---
## 🔒 数据一致性保证
### 1. 事务处理
**关键操作使用事务：**
- 员工调店时：更新旧记录 + 创建新记录（在一个事务中）
- 数据迁移：批量导入使用事务
### 2. 数据校验
**应用层校验：**
- 插入/更新前校验数据完整性和业务逻辑
- 防止数据冲突
**数据库层约束：**
- 外键约束（如果MySQL支持，但通常不使用外键，使用应用层保证）
- 非空约束、唯一约束（根据业务需要）
### 3. 数据同步
**与BASE_USER表同步：**
- 员工调店时，同时更新BASE_USER.F_Mdid和归属表
- 或者：归属表作为数据源，BASE_USER.F_Mdid从归属表计算（当前月份的主要门店）
**建议：**
- BASE_USER.F_Mdid保持为当前门店（实时）
- 归属表记录历史归属
- 两者可以不一致（BASE_USER是当前状态，归属表是历史记录）
---
## 👤 用户体验设计
### 1. 管理界面
#### 1.1 员工门店归属管理页面
**功能：**
- 列表展示：员工、门店、月份、时间范围
- 查询：按员工、门店、月份查询
- 添加：手动添加归属记录
- 编辑：修改归属记录（需要校验）
- 删除：软删除归属记录
- 批量导入：Excel导入
#### 1.2 员工调店操作
**操作流程：**
1. 选择员工
2. 选择目标门店
3. 选择调店日期（默认今天）
4. 系统自动：
  - 查询当前有效归属记录
  - 更新旧记录结束日期
  - 创建新记录开始日期
5. 确认保存
### 2. 数据展示
#### 2.1 员工详情页
**显示：**
- 当前门店：BASE_USER.F_Mdid（实时）
- 历史归属：从归属表查询，列表展示
#### 2.2 工资计算页面
**显示：**
- 如果使用了快照表的门店，显示来源标识
- 如果使用了回退逻辑，显示警告提示
---
## 🔮 扩展性考虑
### 1. 未来可能的业务变化
#### 1.1 多门店归属
**场景：** 一个员工可能同时归属多个门店（兼职）
**扩展方案：**
- 当前设计已经支持（一个员工一个月可以有多条记录）
- 需要调整业务逻辑：工资计算时，如何分配业绩到不同门店
#### 1.2 部门归属
**场景：** 不仅记录门店归属，还要记录部门归属
**扩展方案：**
- 可以增加字段：F_DepartmentId（部门ID）
- 或者创建新的表：员工部门归属表
#### 1.3 岗位变更
**场景：** 记录员工岗位变更历史
**扩展方案：**
- 类似设计：员工岗位归属表
- 或者：在归属表中增加字段：F_Position（岗位）
### 2. 性能扩展
#### 2.1 数据归档
- 历史数据（如3年前的数据）可以归档到历史表
- 当前表只保留最近2-3年的数据
#### 2.2 读写分离
- 如果查询压力大，可以考虑读写分离
- 归属表主要是查询操作，可以放到只读库
---
## ⚠️ 风险点与应对措施
### 1. 数据准确性风险
**风险：** 历史数据迁移可能不准确
**应对：**
- 多数据源验证（工资表、业务数据、人工确认）
- 分批次迁移，每批验证
- 提供数据修正工具
### 2. 性能风险
**风险：** 查询性能可能下降
**应对：**
- 合理设计索引
- 使用缓存
- 监控查询性能，及时优化
### 3. 数据一致性风险
**风险：** 归属表与BASE_USER表可能不一致
**应对：**
- 明确两者的作用：BASE_USER是当前状态，归属表是历史记录
- 提供数据同步工具（可选）
- 在关键操作时校验一致性
### 4. 业务复杂度风险
**风险：** 月中调店等复杂场景增加业务复杂度
**应对：**
- 提供清晰的业务规则文档
- 在管理界面提供操作指引
- 提供数据校验和提示
---
## 📋 实施 Checklist
### 阶段一：数据准备
- 创建归属表结构
- 设计索引
- 编写数据迁移脚本
- 准备测试数据
### 阶段二：功能开发
- 开发归属记录管理功能（CRUD）
- 开发员工调店功能（自动创建归属记录）
- 调整工资计算逻辑（集成快照表）
- 调整数据补录逻辑（集成快照表）
- 开发数据校验逻辑
### 阶段三：数据迁移
- 备份现有数据
- 执行数据迁移（小批量测试）
- 验证数据准确性
- 全量数据迁移
- 数据验证和修正
### 阶段四：测试验证
- 单元测试
- 集成测试
- 性能测试
- 用户验收测试
### 阶段五：上线部署
- 部署到测试环境
- 测试环境验证
- 部署到生产环境
- 监控运行情况
- 数据修正和支持
---
## 🔍 参考现有系统设计
### 1. 现有归属表分析
系统中已经存在类似的归属表设计，可以参考其设计思路：
#### 1.1 大项目部老师归属表（lq_md_major_project_teacher_assignment）
**设计特点：**
- 只记录月份级别（Year + Month），不记录日期范围
- 唯一约束：门店 + 年份 + 月份 + 老师ID
- 一个老师一个月只能有一条记录（不支持月中调店）
**适用场景：**
- 大项目部老师通常是整月归属一个门店
- 如果需要月中调店，需要拆分月份处理
#### 1.2 总经理门店归属表（lq_md_general_manager_lifeline）
**设计特点：**
- 记录月份级别（Month，YYYYMM格式）
- 唯一约束：门店 + 月份 + 总经理ID
- 一个总经理一个月在一个门店只能有一条记录
- 但一个总经理可以管理多个门店（通过多条记录实现）
**适用场景：**
- 总经理/经理通常管理多个门店
- 整月归属，不涉及月中调店
### 2. 设计对比与选择
#### 方案A：按月设计（参考现有归属表）
**特点：**
- 只记录月份级别（Year + Month）
- 一个员工一个月只能有一条记录
- 不支持月中调店（如果需要调店，需要拆分月份）
**优点：**
- 设计简单，与现有归属表一致
- 查询逻辑简单
- 性能好（数据量少）
**缺点：**
- 不支持月中调店场景
- 如果员工在月中调店，需要手动拆分月份
#### 方案B：按日期范围设计（推荐方案）
**特点：**
- 记录日期范围（StartDate + EndDate）
- 一个员工一个月可以有多条记录
- 支持月中调店
**优点：**
- 支持月中调店等复杂场景
- 时间维度精确
- 更灵活
**缺点：**
- 设计相对复杂
- 查询逻辑需要处理日期范围
- 数据量可能更多
### 3. 推荐方案
**建议采用方案B（按日期范围设计）**，理由：
1. **业务需求**：健康师等岗位确实存在月中调店的场景
2. **数据准确性**：日期范围设计更精确，能准确反映实际归属情况
3. **扩展性**：未来如果有更细粒度的需求，日期范围设计更容易扩展
4. **兼容性**：可以与现有按月设计的归属表共存，互不影响
**但是要注意：**
- 如果某些岗位（如大项目部老师、总经理）不需要支持月中调店，可以继续使用现有的按月设计
- 门店归属快照表主要用于健康师、店助、店长等需要精确时间范围的岗位
---
## 💭 额外思考点
### 1. 数据一致性策略
#### 1.1 BASE_USER.F_Mdid 与归属表的关系
**问题：** BASE_USER.F_Mdid 应该如何处理？
**方案A：保持独立**
- BASE_USER.F_Mdid 保持为当前门店（实时状态）
- 归属表记录历史归属
- 两者可以不一致（BASE_USER是当前状态，归属表是历史记录）
**方案B：同步更新**
- 员工调店时，同时更新 BASE_USER.F_Mdid 和归属表
- 保持一致
**方案C：BASE_USER.F_Mdid 从归属表计算**
- BASE_USER.F_Mdid 不再手动维护
- 从归属表计算当前月份的主要门店
- 查询时实时计算或定期同步
**推荐：方案A**
- 理由：BASE_USER.F_Mdid 是实时状态，归属表是历史记录，用途不同
- BASE_USER.F_Mdid 用于当前业务查询（如：查询当前门店的员工）
- 归属表用于历史数据查询（如：计算历史月份工资）
- 两者可以不一致，但需要明确各自的作用
#### 1.2 数据同步策略
**如果采用方案A，需要考虑：**
- 员工调店时，BASE_USER.F_Mdid 和归属表的更新是否需要在同一个事务中？
- 建议：在同一个事务中更新，保证一致性
### 2. 数据维护的便利性
#### 2.1 自动维护 vs 手动维护
**自动维护：**
- 员工调店时，自动创建归属记录
- 优点：减少人工操作，数据准确
- 缺点：如果调店操作本身有问题，归属记录也会有问题
**手动维护：**
- 需要手动创建/编辑归属记录
- 优点：可控性强
- 缺点：增加操作复杂度，可能遗漏
**推荐：混合模式**
- 员工调店时，自动创建归属记录（默认）
- 提供手动维护界面，可以修改/补录
- 支持批量导入历史数据
#### 2.2 数据修正机制
**场景：发现历史归属数据有误**
**处理方案：**
1. **不允许修改历史数据**（严格模式）
  - 如果需要修正，只能删除（软删除）+ 新增
  - 优点：保持数据可追溯性
  - 缺点：操作复杂
2. **允许修改历史数据**（灵活模式）
  - 可以直接修改历史记录
  - 优点：操作简单
  - 缺点：无法追溯修改历史
**推荐：方案1（严格模式）**
- 历史数据一旦创建，不允许直接修改
- 需要修正时，软删除旧记录，创建新记录
- 记录修正原因和操作人
### 3. 查询性能优化
#### 3.1 批量查询优化
**场景：计算某月所有员工的工资**
**优化策略：**
```csharp
// 一次性查询所有员工的归属记录
var employeeIds = allEmployees.Select(e => e.Id).ToList();
var assignments = await _db.Queryable<EmployeeStoreAssignmentEntity>()
    .Where(x => employeeIds.Contains(x.EmployeeId) && x.StatisticsMonth == monthStr)
    .ToListAsync();
// 转换为字典，便于快速查找
var assignmentDict = assignments
    .GroupBy(x => x.EmployeeId)
    .ToDictionary(g => g.Key, g => g.OrderBy(x => x.StartDate).ToList());
```
#### 3.2 缓存策略
**缓存哪些数据？**
- 当前月的归属记录（变化较少）
- 员工当前门店（BASE_USER.F_Mdid）
**缓存失效策略：**
- 归属记录更新时，清除相关缓存
- 定时刷新（如每天凌晨）
#### 3.3 数据分区考虑
**是否需要分区？**
- 如果数据量很大（如10年历史，每月几千员工），可以考虑按年份分区
- 当前阶段可能不需要，但设计时要考虑扩展性
### 4. 异常情况处理
#### 4.1 数据冲突检测
**场景：同一个员工同一天有多条归属记录**
**检测时机：**
- 插入/更新归属记录时
- 数据迁移时
**处理方案：**
- 应用层校验：插入前检查是否有日期重叠
- 如果发现冲突，拒绝操作，提示用户处理
**校验SQL示例：**
```sql
-- 检查是否存在日期重叠
SELECT COUNT(*) 
FROM lq_employee_store_assignment
WHERE F_EmployeeId = @EmployeeId
  AND F_IsEffective = 1
  AND (
    (F_StartDate <= @EndDate AND F_EndDate >= @StartDate)
    OR (F_StartDate IS NULL AND F_EndDate IS NULL)
  )
```
#### 4.2 数据缺失处理
**场景：快照表中没有某员工某月的归属记录**
**处理方案：**
1. **回退到现有逻辑**（推荐）
  - 从业务数据或BASE_USER获取
  - 记录警告日志
  - 可选：自动创建一条归属记录（使用当前门店或推断的门店）
2. **报错处理**
  - 如果快照表没有记录，直接报错
  - 要求用户先维护归属记录
**推荐：方案1**
- 保持系统的容错性
- 记录警告，便于后续补录数据
### 5. 与现有系统的兼容性
#### 5.1 渐进式迁移
**迁移策略：**
1. **第一阶段：新建表，不影响现有逻辑**
  - 创建归属表
  - 数据迁移
  - 但工资计算仍使用现有逻辑
2. **第二阶段：双写模式**
  - 工资计算时，同时使用新逻辑和旧逻辑
  - 对比结果，验证新逻辑的正确性
3. **第三阶段：切换到新逻辑**
  - 新逻辑验证无误后，切换到新逻辑
  - 保留旧逻辑作为回退方案
4. **第四阶段：移除旧逻辑**
  - 新逻辑稳定运行一段时间后，移除旧逻辑
#### 5.2 数据迁移的准确性
**迁移数据来源优先级：**
1. 工资统计表（最可靠）
2. 业务数据统计（补充）
3. BASE_USER当前门店（兜底）
**迁移后的验证：**
- 抽样检查：随机抽取一定比例的数据，人工验证
- 逻辑检查：检查是否有明显异常
- 对比验证：对比迁移前后的工资计算结果
### 6. 未来扩展性
#### 6.1 多门店归属
**场景：一个员工同时归属多个门店（兼职）**
**扩展方案：**
- 当前设计已经支持（一个员工一个月可以有多条记录）
- 需要调整工资计算逻辑：如何分配业绩到不同门店
- 可能需要增加字段：业绩分配比例
#### 6.2 部门归属
**场景：不仅记录门店归属，还要记录部门归属**
**扩展方案：**
- 可以增加字段：F_DepartmentId（部门ID）
- 或者创建新表：员工部门归属表
- 或者：在归属表中增加字段：F_DepartmentId（如果需要同时记录门店和部门）
#### 6.3 岗位变更历史
**场景：记录员工岗位变更历史**
**扩展方案：**
- 可以创建新表：员工岗位归属表（类似设计）
- 或者：在归属表中增加字段：F_Position（岗位）
#### 6.4 其他业务属性
**场景：需要记录其他业务属性（如：职级、薪资等级等）**
**扩展方案：**
- 可以在归属表中增加字段
- 或者创建关联表
**设计原则：**
- 优先考虑在归属表中增加字段（如果属性是时间相关的）
- 如果属性与门店归属无关，考虑创建新表
---
## 📝 总结
门店归属快照表方案是一个相对完善的解决方案，能够：
1. **解决核心问题**：以时间维度为唯一标准，准确记录历史门店归属
2. **支持复杂场景**：月中调店、跨月调店等
3. **保证数据完整性**：通过多数据源验证和数据校验
4. **考虑性能**：合理设计索引和查询优化
5. **易于扩展**：设计时考虑了未来的业务变化
**关键成功因素：**
- 数据迁移的准确性
- 业务规则的清晰性
- 用户操作的简便性
- 系统性能的稳定性
---
**文档版本：** v1.0  
**创建日期：** 2026-01-09  
**文档性质：** 详细设计方案（仅思考，不修改代码）