# 数据模型统一重构方案

## 项目概述
**创建时间**: 2025-01-15  
**执行模式**: 方案B - 完全统一数据模型  
**目标**: 统一vehicle_id为数字ID，license_plate为车牌号，消除所有字段名不一致

## 用户需求
- 采用方案B，统一名称和含义
- license_plate_number和license_plate都采用license_plate
- 统一所有的名称和含义，去掉各种中间转换
- 其他表有类似问题也一样处理

---

## 详细分析

### 🎯 统一规则

1. **vehicle_id**: 所有表中统一为 `BIGINT` 数字ID（主键，自增）
2. **license_plate**: 所有表中统一为 `VARCHAR(50)` 车牌号字段名
3. **关联关系**: 通过 `vehicle_id` 进行主键关联，`license_plate` 作为业务标识

### 📊 影响范围分析

#### 数据库表结构变更

**QAUP-Management:**
```sql
-- 当前: sys_vehicle_info
vehicle_id BIGINT (主键)
license_plate_number VARCHAR(50) → license_plate VARCHAR(50)

-- 变更：重命名字段
ALTER TABLE sys_vehicle_info RENAME COLUMN license_plate_number TO license_plate;
```

**CollisionAvoidanceSystem:**
```sql
-- 当前: vehicle_locations
vehicle_id VARCHAR(50) (车牌号) → BIGINT (数字ID)
新增: license_plate VARCHAR(50) (车牌号)

-- 变更：类型转换 + 新增字段
ALTER TABLE vehicle_locations ADD COLUMN license_plate VARCHAR(50);
ALTER TABLE vehicle_locations ADD COLUMN vehicle_id_new BIGINT;
-- 数据迁移后删除旧字段，重命名新字段
```

#### Java代码变更统计

**QAUP-Management (预计15个文件):**
- `SysVehicleInfo.java` - 实体类字段重命名
- `SysVehicleInfoMapper.xml` - MyBatis映射更新
- `SysVehicleInfoMapper.java` - 接口方法参数
- `SysVehicleInfoService.java` - 服务层逻辑
- `SysVehicleInfoController.java` - 控制器
- 前端Vue组件 - 表单字段和API调用

**CollisionAvoidanceSystem (预计25个文件):**
- 所有包含 `vehicleId` 的实体类（字段类型变更）
- 所有相关的 Repository、Service、Controller
- DTO和转换器类
- WebSocket消息处理类

### 🔄 数据迁移策略

#### 第一阶段：数据结构准备
1. 创建临时字段
2. 建立车牌号到数字ID的映射表
3. 数据完整性检查

#### 第二阶段：数据迁移
1. 填充新字段数据
2. 验证数据一致性
3. 更新外键约束

#### 第三阶段：结构清理
1. 删除旧字段
2. 重命名新字段
3. 重建索引和约束

---

## 实施检查清单

### 1. 数据库结构变更脚本
- [ ] 创建统一的数据库变更脚本
- [ ] 包含回滚脚本
- [ ] 数据完整性验证

### 2. QAUP-Management代码更新
- [ ] 更新SysVehicleInfo实体类
- [ ] 更新MyBatis Mapper文件
- [ ] 更新Service层代码
- [ ] 更新Controller层代码
- [ ] 更新前端Vue组件

### 3. CollisionAvoidanceSystem代码更新
- [ ] 更新所有实体类的vehicle_id字段类型
- [ ] 更新Repository接口
- [ ] 更新Service层逻辑
- [ ] 更新Controller层代码
- [ ] 更新DTO和转换器
- [ ] 更新WebSocket消息处理

### 4. 数据迁移执行
- [ ] 备份现有数据
- [ ] 执行结构变更脚本
- [ ] 执行数据迁移脚本
- [ ] 验证数据完整性

### 5. 测试验证
- [ ] 单元测试更新
- [ ] 集成测试更新
- [ ] 功能测试验证
- [ ] 性能测试验证

### 6. 文档更新
- [ ] API文档更新
- [ ] 数据库文档更新
- [ ] 使用指南更新
- [ ] 版本变更记录

---

## 风险评估

### 🔴 高风险点
1. **数据完整性风险**: 迁移过程中可能的数据丢失
2. **接口兼容性风险**: 外部系统调用可能受影响
3. **系统停机风险**: 结构变更需要服务停机

### 🟡 中风险点
1. **代码兼容性**: 大量代码变更可能引入新bug
2. **性能影响**: 索引重建可能影响查询性能
3. **回滚复杂度**: 变更范围大，回滚操作复杂

### 🟢 低风险点
1. **业务逻辑**: 核心业务逻辑不变
2. **用户体验**: 前端界面基本不变

---

## 实施计划

### 准备阶段（1-2天）
1. 创建完整的数据库变更脚本
2. 创建车牌号到数字ID的映射关系
3. 准备回滚脚本和验证脚本

### 开发阶段（3-5天）
1. 并行更新两个项目的代码
2. 更新所有相关测试用例
3. 本地环境验证

### 测试阶段（2-3天）
1. 完整的数据迁移测试
2. 功能回归测试
3. 性能影响评估

### 部署阶段（1天）
1. 生产环境数据备份
2. 服务停机窗口执行变更
3. 验证和监控

---

## 当前执行步骤
> 正在执行: "1. 分析所有相关表和字段，制定统一的数据模型重构方案"

## 后续步骤预览
1. 创建数据库结构变更脚本
2. 更新QAUP-Management Java实体类
3. 更新CollisionAvoidanceSystem Java实体类
4. 同步Mapper和Repository更新
5. 更新Service层代码
6. 更新API接口
7. 更新前端组件
8. 创建数据迁移脚本
9. 更新测试用例
10. 完整验证和测试

---

## 完成标准

### 数据模型统一
- [ ] 所有表的vehicle_id都是BIGINT类型
- [ ] 所有表的车牌号字段都叫license_plate
- [ ] 消除所有字段名不一致

### 代码质量
- [ ] 所有编译错误已解决
- [ ] 所有单元测试通过
- [ ] 代码风格一致

### 功能验证
- [ ] 车辆管理功能正常
- [ ] 实时位置监控正常
- [ ] 数据关联查询正常
- [ ] API接口响应正确

### 性能验证
- [ ] 查询性能不降低
- [ ] 数据库索引优化
- [ ] 内存使用正常