上传源代码版本

Label_Update_Timestamp_Spec.md

@@ -0,0 +1,123 @@
+# 标签更新时间记录方案分析
+
+## 1. 需求概述
+
+在客户通过标签替换接口更新标签时，需要记录客户更新标签的时间。目前有两套方案：
+- 方案1：采用数据库trigger去实现，数据库是mysql。
+- 方案2：修改代码逻辑。
+
+## 2. 现状分析
+
+### 2.1 数据库结构
+
+`LabelReplaceEntity` 类映射到 `label_replace_requests` 表，包含以下时间相关字段：
+
+```csharp
+/// <summary>
+/// 创建时间
+/// </summary>
+[SugarColumn(IsNullable = false)]
+public DateTime CreatedAt { get; set; } = DateTime.UtcNow;
+
+/// <summary>
+/// 更新时间
+/// </summary>
+[SugarColumn(IsNullable = false)]
+public DateTime UpdatedAt { get; set; } = DateTime.UtcNow;
+```
+
+### 2.2 代码逻辑
+
+1. **LabelReplaceRepository.CreateAsync** 方法：
+   ```csharp
+   // 设置时间戳
+   entity.CreatedAt = DateTime.UtcNow;
+   entity.UpdatedAt = DateTime.UtcNow;
+   ```
+
+2. **LabelReplaceRepository.UpdateAsync** 方法：
+   ```csharp
+   // 更新时间戳
+   entity.UpdatedAt = DateTime.UtcNow;
+   ```
+
+3. **LabelReplaceService.ProcessLabelReplaceAsync** 方法：
+   ```csharp
+   // 更新现有记录时
+   existingRecord.UpdatedAt = DateTime.UtcNow;
+   ```
+
+## 3. 方案分析
+
+### 3.1 方案1：数据库Trigger
+
+**实现方式**：
+- 在MySQL数据库中为 `label_replace_requests` 表创建一个更新触发器
+- 当记录被更新时，自动将 `UpdatedAt` 字段设置为当前时间
+
+**优点**：
+- 数据库层面自动处理，无需修改应用代码
+- 无论通过什么方式更新数据，都会自动更新时间戳
+- 确保时间戳更新的一致性
+
+**缺点**：
+- 增加了数据库的复杂性
+- 触发器可能会影响数据库性能，特别是在高频更新场景下
+- 代码逻辑和时间戳更新逻辑分离，不利于维护
+- 需要数据库管理员权限来创建触发器
+
+### 3.2 方案2：修改代码逻辑
+
+**实现方式**：
+- 确保所有更新操作都通过 `LabelReplaceRepository.UpdateAsync` 方法
+- 利用现有的代码逻辑，在更新时自动设置 `UpdatedAt` 字段
+
+**优点**：
+- 代码逻辑和时间戳更新逻辑集中在一处，便于维护
+- 不需要修改数据库结构
+- 性能影响小，不会增加数据库负担
+- 符合现有的代码架构
+
+**缺点**：
+- 需要确保所有更新操作都通过相同的代码路径
+- 如果有其他地方直接操作数据库，可能会导致时间戳不更新
+
+## 4. 性能分析
+
+### 4.1 方案1（数据库Trigger）
+- **性能影响**：每次更新操作都会触发触发器，增加数据库负载
+- **适用场景**：数据更新频率较低，需要确保时间戳一致性的场景
+
+### 4.2 方案2（代码逻辑）
+- **性能影响**：仅在代码层面设置时间戳，几乎无性能影响
+- **适用场景**：数据更新频率较高，系统架构清晰的场景
+
+## 5. 推荐方案
+
+**推荐方案**：方案2（修改代码逻辑）
+
+**推荐理由**：
+1. **符合现有架构**：系统已经在使用代码逻辑的方式来更新时间戳，保持一致性
+2. **性能优势**：代码层面设置时间戳，无数据库性能开销
+3. **维护性好**：代码逻辑和时间戳更新逻辑集中在一处，便于理解和维护
+4. **无需额外权限**：不需要数据库管理员权限来创建触发器
+5. **可靠性高**：现有代码已经实现了时间戳更新逻辑，只需确保所有更新操作都通过该逻辑
+
+**关键修改**：
+1. 确保所有更新 `label_replace_requests` 表的操作都通过 `LabelReplaceRepository.UpdateAsync` 方法
+2. 验证 `LabelReplaceService.ProcessLabelReplaceAsync` 方法中的时间戳更新逻辑是否正确
+3. 考虑在 `LabelReplaceEntity` 类中添加构造函数，确保 `CreatedAt` 和 `UpdatedAt` 字段始终有默认值
+
+## 6. 验证方法
+
+1. **功能验证**：
+   - 发送标签替换请求，验证 `UpdatedAt` 字段是否被更新
+   - 发送多次请求，验证每次请求后 `UpdatedAt` 字段是否都被更新为最新时间
+
+2. **性能验证**：
+   - 批量发送标签替换请求，测量响应时间
+   - 比较使用方案2前后的性能差异
+
+## 7. 结论
+
+方案2（修改代码逻辑）是性能最高、最合理的方案。它符合现有系统架构，性能影响小，维护性好，并且已经在系统中实现。只需确保所有更新操作都通过现有的代码逻辑，即可实现记录客户更新标签时间的需求。