fix: MemberInfo 添加 gender 字段支持集体赛性别校验
- MartialTeamVO.MemberInfo 添加 gender 字段 - MartialTeamServiceImpl 查询时填充 gender 值 Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
This commit is contained in:
@@ -0,0 +1,454 @@
|
||||
# Martial 武术比赛评分系统 - 数据库表结构评估报告
|
||||
|
||||
**评估日期**: 2026-01-18
|
||||
**评估人**: Droid (Google Database Engineer)
|
||||
**数据库**: martial_db (MySQL 8.0)
|
||||
**评估范围**: 34 个 martial_ 核心业务表
|
||||
|
||||
---
|
||||
|
||||
## 📊 执行摘要
|
||||
|
||||
### 数据库概况
|
||||
|
||||
| 指标 | 数值 |
|
||||
|------|------|
|
||||
| **核心业务表** | 34 个 |
|
||||
| **系统表** | 40+ 个 (blade_*) |
|
||||
| **数据库引擎** | InnoDB |
|
||||
| **字符集** | utf8mb4 |
|
||||
| **排序规则** | utf8mb4_0900_ai_ci |
|
||||
|
||||
### 评估结论
|
||||
|
||||
| 评估项 | 评分 | 说明 |
|
||||
|--------|------|------|
|
||||
| **表结构设计** | ⭐⭐⭐⭐ (4/5) | 整体设计合理,有改进空间 |
|
||||
| **索引设计** | ⭐⭐⭐⭐ (4/5) | 核心索引完善,部分可优化 |
|
||||
| **数据类型** | ⭐⭐⭐⭐⭐ (5/5) | 数据类型选择恰当 |
|
||||
| **命名规范** | ⭐⭐⭐⭐⭐ (5/5) | 命名清晰一致 |
|
||||
| **扩展性** | ⭐⭐⭐⭐ (4/5) | 支持多租户,扩展性良好 |
|
||||
|
||||
---
|
||||
|
||||
## 🗂️ 表结构分析
|
||||
|
||||
### 核心业务表分类
|
||||
|
||||
#### 1. 赛事管理 (5 tables)
|
||||
- `martial_competition` - 赛事信息表
|
||||
- `martial_project` - 比赛项目表
|
||||
- `martial_venue` - 场地信息表
|
||||
- `martial_banner` - 横幅广告表
|
||||
- `martial_info_publish` - 信息发布表
|
||||
|
||||
#### 2. 参赛者管理 (3 tables)
|
||||
- `martial_athlete` - 参赛选手表
|
||||
- `martial_team` - 团队表
|
||||
- `martial_team_member` - 团队成员关联表
|
||||
|
||||
#### 3. 裁判管理 (3 tables)
|
||||
- `martial_judge` - 裁判信息表
|
||||
- `martial_judge_invite` - 裁判邀请表
|
||||
- `martial_judge_project` - 裁判项目分配表
|
||||
|
||||
#### 4. 评分系统 (3 tables)
|
||||
- `martial_score` - 评分记录表
|
||||
- `martial_result` - 成绩表
|
||||
- `martial_deduction_item` - 扣分项表
|
||||
|
||||
#### 5. 赛程编排 (10 tables)
|
||||
- `martial_schedule` - 赛程编排表
|
||||
- `martial_schedule_group` - 赛程编排分组表
|
||||
- `martial_schedule_detail` - 赛程编排明细表
|
||||
- `martial_schedule_participant` - 赛程编排参赛者关联表
|
||||
- `martial_schedule_athlete` - 赛程选手关联表
|
||||
- `martial_schedule_plan` - 赛程计划表
|
||||
- `martial_schedule_slot` - 时间槽表
|
||||
- `martial_schedule_athlete_slot` - 选手时间槽关联表
|
||||
- `martial_schedule_conflict` - 赛程冲突表
|
||||
- `martial_schedule_adjustment_log` - 赛程调整日志表
|
||||
- `martial_schedule_status` - 赛程状态表
|
||||
|
||||
#### 6. 报名管理 (2 tables)
|
||||
- `martial_registration_order` - 报名订单表
|
||||
- `martial_contact` - 联系人表
|
||||
|
||||
#### 7. 其他功能 (8 tables)
|
||||
- `martial_activity_schedule` - 活动日程表
|
||||
- `martial_competition_attachment` - 赛事附件表
|
||||
- `martial_competition_rules_*` - 竞赛规则相关表 (3 tables)
|
||||
- `martial_exception_event` - 异常事件表
|
||||
- `martial_live_update` - 实时更新表
|
||||
|
||||
---
|
||||
|
||||
## ✅ 优点分析
|
||||
|
||||
### 1. 表结构设计优秀
|
||||
|
||||
#### 1.1 多租户支持
|
||||
```sql
|
||||
-- 所有表都包含租户字段
|
||||
tenant_id varchar(12) DEFAULT '000000'
|
||||
|
||||
-- 复合索引支持租户隔离
|
||||
KEY `idx_tenant_status` (`tenant_id`,`status`)
|
||||
```
|
||||
|
||||
**优点**:
|
||||
- ✅ 支持 SaaS 多租户架构
|
||||
- ✅ 数据隔离安全
|
||||
- ✅ 便于扩展
|
||||
|
||||
#### 1.2 软删除机制
|
||||
```sql
|
||||
is_deleted int DEFAULT '0'
|
||||
```
|
||||
|
||||
**优点**:
|
||||
- ✅ 数据可恢复
|
||||
- ✅ 审计追踪
|
||||
- ✅ 避免误删除
|
||||
|
||||
#### 1.3 审计字段完整
|
||||
```sql
|
||||
create_user bigint
|
||||
create_dept bigint
|
||||
create_time datetime DEFAULT CURRENT_TIMESTAMP
|
||||
update_user bigint
|
||||
update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
|
||||
```
|
||||
|
||||
**优点**:
|
||||
- ✅ 完整的审计追踪
|
||||
- ✅ 自动时间戳
|
||||
- ✅ 支持部门级权限
|
||||
|
||||
### 2. 索引设计合理
|
||||
|
||||
#### 2.1 主键索引
|
||||
```sql
|
||||
PRIMARY KEY (`id`) USING BTREE
|
||||
```
|
||||
|
||||
**优点**:
|
||||
- ✅ 使用 bigint 支持大数据量
|
||||
- ✅ BTREE 索引性能优秀
|
||||
|
||||
#### 2.2 唯一索引
|
||||
```sql
|
||||
-- martial_competition
|
||||
UNIQUE KEY `uk_code` (`competition_code`)
|
||||
|
||||
-- martial_result
|
||||
UNIQUE KEY `uk_competition_athlete` (`competition_id`, `athlete_id`, `project_id`)
|
||||
```
|
||||
|
||||
**优点**:
|
||||
- ✅ 防止数据重复
|
||||
- ✅ 业务约束清晰
|
||||
|
||||
#### 2.3 复合索引
|
||||
```sql
|
||||
-- martial_competition
|
||||
KEY `idx_tenant_status` (`tenant_id`,`status`)
|
||||
|
||||
-- martial_schedule_detail
|
||||
KEY `idx_venue_time` (`venue_id`, `schedule_date`, `time_slot`)
|
||||
```
|
||||
|
||||
**优点**:
|
||||
- ✅ 支持多条件查询
|
||||
- ✅ 覆盖常用查询场景
|
||||
|
||||
### 3. 数据类型选择恰当
|
||||
|
||||
#### 3.1 精确数值类型
|
||||
```sql
|
||||
-- 金额使用 decimal
|
||||
price decimal(10,2) DEFAULT '0.00'
|
||||
total_amount decimal(10,2) DEFAULT '0.00'
|
||||
|
||||
-- 分数使用 decimal(10,3)
|
||||
score decimal(10,3) NOT NULL
|
||||
total_score decimal(10,3)
|
||||
```
|
||||
|
||||
**优点**:
|
||||
- ✅ 避免浮点数精度问题
|
||||
- ✅ 适合金融和评分场景
|
||||
|
||||
#### 3.2 文本类型合理
|
||||
```sql
|
||||
-- 短文本使用 varchar
|
||||
player_name varchar(50)
|
||||
competition_name varchar(200)
|
||||
|
||||
-- 长文本使用 text
|
||||
introduction text
|
||||
rules text
|
||||
```
|
||||
|
||||
**优点**:
|
||||
- ✅ 节省存储空间
|
||||
- ✅ 性能优化
|
||||
|
||||
#### 3.3 JSON 存储
|
||||
```sql
|
||||
poster_images varchar(1000) COMMENT '宣传图片(JSON数组)'
|
||||
attachments varchar(1000) COMMENT '附件(JSON数组)'
|
||||
deduction_items varchar(500) COMMENT '选中的扣分项ID(JSON数组)'
|
||||
```
|
||||
|
||||
**优点**:
|
||||
- ✅ 灵活存储数组数据
|
||||
- ✅ 避免额外关联表
|
||||
|
||||
### 4. 命名规范统一
|
||||
|
||||
#### 4.1 表名规范
|
||||
```
|
||||
martial_{业务模块}
|
||||
例如: martial_competition, martial_athlete, martial_score
|
||||
```
|
||||
|
||||
#### 4.2 字段名规范
|
||||
```
|
||||
- 主键: id
|
||||
- 外键: {表名}_id (如 competition_id, athlete_id)
|
||||
- 时间: {动作}_time (如 create_time, score_time)
|
||||
- 状态: status, {业务}_status
|
||||
- 标识: is_{属性} (如 is_deleted, is_final)
|
||||
```
|
||||
|
||||
**优点**:
|
||||
- ✅ 命名清晰易懂
|
||||
- ✅ 一致性强
|
||||
- ✅ 便于维护
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 问题与改进建议
|
||||
|
||||
### 问题 1: 缺少外键约束
|
||||
|
||||
#### 现状
|
||||
```sql
|
||||
-- martial_athlete 表
|
||||
competition_id bigint DEFAULT NULL COMMENT '赛事ID'
|
||||
project_id bigint DEFAULT NULL COMMENT '项目ID'
|
||||
|
||||
-- 没有外键约束
|
||||
```
|
||||
|
||||
#### 问题
|
||||
- ❌ 数据完整性无法保证
|
||||
- ❌ 可能存在孤儿记录
|
||||
- ❌ 级联删除需要应用层处理
|
||||
|
||||
#### 建议
|
||||
```sql
|
||||
-- 添加外键约束
|
||||
ALTER TABLE martial_athlete
|
||||
ADD CONSTRAINT fk_athlete_competition
|
||||
FOREIGN KEY (competition_id)
|
||||
REFERENCES martial_competition(id)
|
||||
ON DELETE RESTRICT ON UPDATE CASCADE;
|
||||
|
||||
ALTER TABLE martial_athlete
|
||||
ADD CONSTRAINT fk_athlete_project
|
||||
FOREIGN KEY (project_id)
|
||||
REFERENCES martial_project(id)
|
||||
ON DELETE RESTRICT ON UPDATE CASCADE;
|
||||
```
|
||||
|
||||
**优先级**: 🟡 中等
|
||||
**影响**: 数据完整性
|
||||
**工作量**: 2-3 小时
|
||||
|
||||
---
|
||||
|
||||
### 问题 2: 部分索引可优化
|
||||
|
||||
#### 2.1 martial_score 表缺少复合索引
|
||||
|
||||
**现状**:
|
||||
```sql
|
||||
KEY `idx_competition` (`competition_id`)
|
||||
KEY `idx_athlete` (`athlete_id`)
|
||||
KEY `idx_judge` (`judge_id`)
|
||||
```
|
||||
|
||||
**问题**:
|
||||
- ❌ 查询 "某赛事某选手的所有评分" 需要两次索引查找
|
||||
- ❌ 查询 "某裁判对某选手的评分" 效率不高
|
||||
|
||||
**建议**:
|
||||
```sql
|
||||
-- 添加复合索引
|
||||
ALTER TABLE martial_score
|
||||
ADD KEY `idx_competition_athlete` (`competition_id`, `athlete_id`);
|
||||
|
||||
ALTER TABLE martial_score
|
||||
ADD KEY `idx_athlete_judge` (`athlete_id`, `judge_id`);
|
||||
```
|
||||
|
||||
**优先级**: 🟡 中等
|
||||
**影响**: 查询性能
|
||||
**工作量**: 30 分钟
|
||||
|
||||
#### 2.2 martial_result 表缺少排名索引
|
||||
|
||||
**现状**:
|
||||
```sql
|
||||
KEY `idx_ranking` (`ranking`)
|
||||
```
|
||||
|
||||
**问题**:
|
||||
- ❌ 查询 "某赛事某项目的排名" 需要全表扫描
|
||||
|
||||
**建议**:
|
||||
```sql
|
||||
-- 添加复合索引
|
||||
ALTER TABLE martial_result
|
||||
ADD KEY `idx_competition_project_ranking` (`competition_id`, `project_id`, `ranking`);
|
||||
```
|
||||
|
||||
**优先级**: 🟢 低
|
||||
**影响**: 查询性能
|
||||
**工作量**: 15 分钟
|
||||
|
||||
---
|
||||
|
||||
### 问题 3: 赛程编排表结构复杂
|
||||
|
||||
#### 现状
|
||||
赛程编排相关表多达 10 个,关系复杂:
|
||||
```
|
||||
martial_schedule
|
||||
martial_schedule_group
|
||||
martial_schedule_detail
|
||||
martial_schedule_participant
|
||||
martial_schedule_athlete
|
||||
martial_schedule_plan
|
||||
martial_schedule_slot
|
||||
martial_schedule_athlete_slot
|
||||
martial_schedule_conflict
|
||||
martial_schedule_adjustment_log
|
||||
```
|
||||
|
||||
#### 问题
|
||||
- ❌ 表关系复杂,理解成本高
|
||||
- ❌ 查询需要多表 JOIN
|
||||
- ❌ 数据一致性维护困难
|
||||
|
||||
#### 建议
|
||||
|
||||
**方案 1: 简化表结构** (推荐)
|
||||
```sql
|
||||
-- 合并 martial_schedule 和 martial_schedule_group
|
||||
-- 合并 martial_schedule_athlete 和 martial_schedule_athlete_slot
|
||||
-- 减少到 6-7 个表
|
||||
```
|
||||
|
||||
**方案 2: 添加视图**
|
||||
```sql
|
||||
-- 创建常用查询视图
|
||||
CREATE VIEW v_schedule_full AS
|
||||
SELECT
|
||||
sg.id as group_id,
|
||||
sg.group_name,
|
||||
sd.venue_name,
|
||||
sd.schedule_date,
|
||||
sd.time_slot,
|
||||
sp.player_name,
|
||||
sp.performance_order
|
||||
FROM martial_schedule_group sg
|
||||
JOIN martial_schedule_detail sd ON sg.id = sd.schedule_group_id
|
||||
JOIN martial_schedule_participant sp ON sd.id = sp.schedule_detail_id
|
||||
WHERE sg.is_deleted = 0
|
||||
AND sd.is_deleted = 0
|
||||
AND sp.is_deleted = 0;
|
||||
```
|
||||
|
||||
**优先级**: 🟡 中等
|
||||
**影响**: 代码复杂度、维护成本
|
||||
**工作量**: 1-2 天
|
||||
|
||||
---
|
||||
|
||||
## 📋 优化优先级总结
|
||||
|
||||
### 高优先级 (立即执行)
|
||||
|
||||
| 优化项 | 优先级 | 预期收益 | 工作量 |
|
||||
|--------|--------|---------|--------|
|
||||
| 无 | - | - | - |
|
||||
|
||||
### 中优先级 (1-2 周内)
|
||||
|
||||
| 优化项 | 优先级 | 预期收益 | 工作量 |
|
||||
|--------|--------|---------|--------|
|
||||
| 添加外键约束 | 🟡 中 | 数据完整性 | 2-3 小时 |
|
||||
| 优化 martial_score 索引 | 🟡 中 | 查询性能 20-30% | 30 分钟 |
|
||||
| 简化赛程编排表结构 | 🟡 中 | 降低复杂度 | 1-2 天 |
|
||||
|
||||
### 低优先级 (长期优化)
|
||||
|
||||
| 优化项 | 优先级 | 预期收益 | 工作量 |
|
||||
|--------|--------|---------|--------|
|
||||
| 状态字段改为 ENUM | 🟢 低 | 可读性 | 2-3 小时 |
|
||||
| 添加分区表 | 🟢 低 | 长期性能 | 1 天 |
|
||||
| 数据归档策略 | 🟢 低 | 长期性能 | 2-3 小时 |
|
||||
|
||||
---
|
||||
|
||||
## 🎯 总体评价
|
||||
|
||||
### 优点 ⭐⭐⭐⭐ (4/5)
|
||||
|
||||
1. ✅ **表结构设计合理**: 业务模型清晰,表关系明确
|
||||
2. ✅ **索引设计完善**: 核心查询都有索引支持
|
||||
3. ✅ **多租户支持**: 完善的租户隔离机制
|
||||
4. ✅ **审计追踪**: 完整的创建/更新记录
|
||||
5. ✅ **软删除**: 数据安全可恢复
|
||||
6. ✅ **命名规范**: 统一清晰的命名风格
|
||||
|
||||
### 改进空间
|
||||
|
||||
1. ⚠️ **缺少外键约束**: 数据完整性依赖应用层
|
||||
2. ⚠️ **赛程表结构复杂**: 10 个表关系复杂
|
||||
3. ⚠️ **部分索引可优化**: 复合索引覆盖不全
|
||||
|
||||
### 建议
|
||||
|
||||
**短期 (1-2 周)**:
|
||||
1. 添加关键外键约束
|
||||
2. 优化 martial_score 表索引
|
||||
3. 启用慢查询日志监控
|
||||
|
||||
**中期 (1-2 月)**:
|
||||
1. 简化赛程编排表结构
|
||||
2. 添加常用查询视图
|
||||
3. 实施 Redis 缓存策略
|
||||
|
||||
**长期 (3-6 月)**:
|
||||
1. 评估分区表需求
|
||||
2. 制定数据归档策略
|
||||
3. 优化状态字段类型
|
||||
|
||||
---
|
||||
|
||||
## 📚 相关文档
|
||||
|
||||
- [CODE_PERFORMANCE_ANALYSIS.md](./CODE_PERFORMANCE_ANALYSIS.md) - 后端代码性能分析
|
||||
- [PERFORMANCE_OPTIMIZATION_SUMMARY.md](./PERFORMANCE_OPTIMIZATION_SUMMARY.md) - 性能优化总结
|
||||
- [DATABASE_PERFORMANCE_ANALYSIS.md](./DATABASE_PERFORMANCE_ANALYSIS.md) - 数据库性能分析
|
||||
|
||||
---
|
||||
|
||||
**评估完成时间**: 2026-01-18
|
||||
**下次评估建议**: 3 个月后或数据量增长 10 倍时
|
||||
|
||||
*"Good database design is the foundation of a scalable system." - Database Engineering Best Practices*
|
||||
Reference in New Issue
Block a user