292 lines
8.4 KiB
Markdown
292 lines
8.4 KiB
Markdown
# 项目梳理（第一轮）
|
||
|
||
## 1. 已确认的基础约束
|
||
|
||
- 技术方向：`Python + Flask` 后端，前端需要单独界面。
|
||
- 数据库：`PostgreSQL`。
|
||
- 部署方式：前后端都部署在 NAS 上，并以 `Docker` 形式运行。
|
||
- 敏感信息：**不读取** `.env`，仅参考 `.env.example`。
|
||
- 当前代码状态：项目基本还是空白，`main.py` 仍是 PyCharm 初始化示例。
|
||
|
||
## 2. 环境变量格式（来自 `.env.example`）
|
||
|
||
当前已知 PG 连接相关变量格式如下：
|
||
|
||
- `PGHOST`
|
||
- `PGPORT`
|
||
- `PGUSER`
|
||
- `PGPASSWORD`
|
||
- `PGDATABASE`
|
||
- `APP_ENV`
|
||
- `APP_PORT`
|
||
|
||
说明：后续 Flask 项目可以直接按这一组变量读取数据库连接信息。
|
||
|
||
## 3. Excel 工作簿结构梳理
|
||
|
||
文件：`KSP Engine Tweak Chart.xlsx`
|
||
|
||
实际工作表如下：
|
||
|
||
1. `Engine Database`（核心）
|
||
2. `Communication`
|
||
3. `work area`（可忽略）
|
||
4. `Fuel Chart`
|
||
5. `Tank Chart`
|
||
6. `Launch Cost`
|
||
7. `KSP Vehicle Cost`
|
||
8. `Tube`（可忽略）
|
||
9. `TQ series`（可忽略）
|
||
|
||
## 4. 各表初步理解
|
||
|
||
### 4.1 `Engine Database`
|
||
|
||
- 规模：约 `478` 条数据。
|
||
- 核心程度最高，后续数据库设计应以此为中心。
|
||
- 表头如下：
|
||
1. `Engine`
|
||
2. `Fuel Type`
|
||
3. `Cycle`
|
||
4. `Work Env`
|
||
5. `SL-ISP`
|
||
6. `Vac-ISP`
|
||
7. `Min Thrust`
|
||
8. `Max Thrust`
|
||
9. `Mass`
|
||
10. `TWR`
|
||
11. `Throttle Range`
|
||
12. `TVC`
|
||
13. `Size`
|
||
14. `Price KD`
|
||
15. `entry Cost`
|
||
16. `Ignitions`
|
||
17. `Classification`
|
||
18. `Note`
|
||
19. `Name`
|
||
20. `Config Name`
|
||
21. `TechRequired`
|
||
22. `Config Note`
|
||
|
||
#### 观察
|
||
|
||
- `TWR` 基本是公式列，公式看起来是：`Max Thrust / 9.80665 / Mass`。
|
||
- `Throttle Range` 基本也是公式列，公式看起来是：`Min Thrust / Max Thrust`。
|
||
- 同一个 `Engine` 会有多条记录，代表不同配置/燃料/版本。
|
||
- `Name`、`Config Name`、`TechRequired` 有较多空值，说明这些字段并不是所有引擎都有。
|
||
- 仅用 `(Name, Config Name)` 作为唯一键 **不可靠**，发现有重复情况。
|
||
|
||
#### 目前推测
|
||
|
||
后续数据库大概率需要拆成两层：
|
||
|
||
- `engine_base`：存引擎主体信息（名称、来源、尺寸、分类等）
|
||
- `engine_variant`：存具体配置（燃料、ISP、推力、点火次数、科技树要求等）
|
||
|
||
但这需要你确认字段含义后再定。
|
||
|
||
---
|
||
|
||
### 4.2 `Communication`
|
||
|
||
- 规模：约 `50` 条数据。
|
||
- 主要记录天线/通信部件。
|
||
- 字段包括：部件名、显示名、质量、是否主动、是否可展开、类型、展开直径、通信距离、角度、速度、功耗、来源、成本、缩放信息等。
|
||
|
||
#### 观察
|
||
|
||
- `Range km` / `Range AU` / `Range Light year` 看起来是由 `Range Raw` 换算而来。
|
||
- `idle power watt` / `transmitting power watt` 也是公式列。
|
||
- `Tech` 列目前看起来全部为空，可能是未整理，或者本来不用。
|
||
- `Is Feeder`、`Is Deployable`、`Is Active` 是布尔型字段。
|
||
|
||
---
|
||
|
||
### 4.3 `Fuel Chart`
|
||
|
||
这是一个**换算工具型表**，目前并不像主数据表，更适合作为后端计算逻辑或前端小工具。
|
||
|
||
#### 当前看到的结构
|
||
|
||
- 第一行：燃料类型，如 `HTPB`、`Solid`、`PBAN`、`Kerolox`、`Hydrolox`、`Methalox`、`Hydrazine`、`MMH/NTO`
|
||
- 第二行：每升体积对应质量（看起来像密度/换算系数）
|
||
- 第三、四行：
|
||
- 输入体积（L）后，计算不同燃料的质量
|
||
- 输入质量（t）后，反推出不同燃料的体积
|
||
|
||
#### 目前判断
|
||
|
||
这个表不一定要入库；更适合实现为：
|
||
|
||
- 一个独立 API
|
||
- 或前端页面里的快速换算器
|
||
- 或后端的纯函数工具模块
|
||
|
||
---
|
||
|
||
### 4.4 `Tank Chart`
|
||
|
||
- 规模：约 `26` 条数据。
|
||
- 字段包括：
|
||
- `Tank`
|
||
- `Fuel Type`
|
||
- `Dry Mass`
|
||
- `Fuel Mass`
|
||
- `Wet Mass`
|
||
- `Tank Volume(L)`
|
||
- `Mass Ratio`
|
||
- `KL per ton`
|
||
- `Vehicle`
|
||
- `Source`
|
||
- `Note`
|
||
|
||
#### 观察
|
||
|
||
- `Wet Mass`、`Mass Ratio`、`KL per ton` 中很多是公式列。
|
||
- `Fuel Type` 当前主要是 `Kerolox` / `Hydrolox` / `Methalox`。
|
||
- 这个表适合作为“燃料箱/级段参数资料表”。
|
||
|
||
---
|
||
|
||
### 4.5 `KSP Vehicle Cost`
|
||
|
||
- 规模：约 `10` 条数据。
|
||
- 字段比较简单：
|
||
- `Vehicle`
|
||
- `Launch Price`
|
||
- `Source`
|
||
|
||
#### 观察
|
||
|
||
- 有部分 `Launch Price` 为空，需确认是“未知”还是“待补充”。
|
||
|
||
## 5. 当前我整理出的数据建模方向（草案）
|
||
|
||
> 这里只是第一轮草案，等你确认字段含义后再正式定表结构。
|
||
|
||
### 核心主表建议
|
||
|
||
1. `engines` / `engine_base`
|
||
- 引擎基础信息
|
||
- 如：名称、来源/分类、尺寸、备注、内部标识等
|
||
|
||
2. `engine_variants`
|
||
- 引擎配置项
|
||
- 如：燃料类型、循环方式、适用环境、SL/Vac ISP、推力范围、质量、TVC、点火次数、价格、科技节点等
|
||
|
||
### 配套表建议
|
||
|
||
3. `communication_parts`
|
||
4. `tank_specs`
|
||
5. `vehicle_costs`
|
||
6. `fuel_conversion_rules`（不一定入库，也可能直接写成程序常量）
|
||
|
||
## 6. 第一轮需要你确认的问题
|
||
|
||
下面这些问题会直接影响数据库设计和前端表单设计：
|
||
|
||
### 关于 `Engine Database`
|
||
|
||
1. `Work Env` 的枚举含义是什么？
|
||
- 目前看到像 `Lower`、`Upper` 等，是否表示适用飞行环境/任务场景？
|
||
|
||
2. `Classification` 是什么语义？
|
||
- 是模组来源（如 `Squad`、`NFS`、`Ven`、`Real/...`）
|
||
- 还是引擎分类标签？
|
||
|
||
3. `Name` 是不是游戏/模组里的**内部 part name**？
|
||
- 如果是，为什么有相当多记录为空？
|
||
|
||
4. `Config Name` 是不是某个引擎的配置名/variant 名？
|
||
- 如果是，它显然不是全局唯一键；后续唯一标识你倾向于用什么？
|
||
- `Engine + Fuel Type + Config Name`？还是另有内部 ID？
|
||
|
||
5. `Price KD` 是不是 Kerbal Dollars 的部件价格？
|
||
6. `entry Cost` 是不是科技树解锁成本 / 研发成本？
|
||
7. `TVC` 的单位是否是“度”（gimbal range）？
|
||
8. `Size` 的单位是否是米（或零件直径规格）？
|
||
9. `Ignitions` 为空时表示：
|
||
- 无限次？
|
||
- 未知？
|
||
- 不适用？
|
||
10. `Note` 与 `Config Note` 的区别是什么？
|
||
- 一个是引擎总体备注，一个是某个配置备注？
|
||
|
||
### 关于 `Fuel Chart`
|
||
|
||
11. 这个换算功能你希望最终怎么实现？
|
||
- 单独页面小工具
|
||
- 引擎/燃料箱录入时的辅助计算器
|
||
- 还是后端提供一个简单 API 即可
|
||
|
||
12. 第二行这些值，本质上是不是“燃料密度 / 升到吨的换算系数”？
|
||
- 如果是，我后续会直接把它们做成程序配置或数据库字典表。
|
||
|
||
### 关于 `KSP Vehicle Cost`
|
||
|
||
13. `Launch Price` 为空的行，是不是表示“暂无数据，允许为空”？
|
||
|
||
## 7. 下一步建议
|
||
|
||
等你回答上面的问题后，我建议立即进入下面阶段：
|
||
|
||
1. 先把 `Engine Database` 字段定义彻底确认
|
||
2. 画出数据库草图（PostgreSQL）
|
||
3. 确定 Flask 后端模块划分
|
||
4. 确定前端页面：列表 / 搜索 / 详情 / 编辑 / 导入
|
||
5. 再开始初始化项目结构、Docker、数据库迁移、Excel 导入脚本
|
||
|
||
## 8. 第二轮落地结论（已按 Excel 实际数据校验）
|
||
|
||
### 8.1 唯一键结论
|
||
|
||
- `Engine + Config Name` 在当前工作簿中有 `48` 组重复。
|
||
- 即使补上 `Fuel Type`，仍然还有 `19` 组重复。
|
||
- 这意味着数据库不能直接把自然键硬编码成唯一约束，否则导入会失败。
|
||
|
||
### 8.2 `Engine Database` 的稳定字段边界
|
||
|
||
按同名 `Engine` 聚合后，当前数据呈现出下面的规律：
|
||
|
||
- 基本稳定：`Name`、`Cycle`、`Size`、`entry Cost`
|
||
- 明显会变化：`Fuel Type`、`Work Env`、`TVC`、`Price KD`、`Classification`、`Note`、`Config Name`
|
||
|
||
所以更稳妥的拆分是：
|
||
|
||
1. `engine_families`
|
||
- `engine_name`
|
||
- `part_name`
|
||
- `cycle`
|
||
- `size_m`
|
||
- `entry_cost`
|
||
2. `engine_variants`
|
||
- 所有配置级字段
|
||
- 使用代理主键
|
||
- 保留原始自然键字段用于展示和导入告警
|
||
|
||
### 8.3 当前实现层面的架构选择
|
||
|
||
- 先采用 **单 Flask 应用**：同时提供
|
||
- Jinja 前端页面
|
||
- JSON API
|
||
- PostgreSQL 数据访问层
|
||
- 这样部署到 NAS 时只需要一个应用容器，复杂度最低。
|
||
- 如果后续页面复杂度变高，再把前端拆成独立工程也不迟。
|
||
|
||
### 8.4 已确定的第一批落地内容
|
||
|
||
1. Flask 项目骨架
|
||
2. SQLAlchemy 数据模型
|
||
3. Dockerfile 与 docker-compose 基线
|
||
4. Excel 巡检脚本
|
||
5. Fuel Chart 小工具页面与 API
|
||
|
||
### 8.5 下一阶段直接衔接的工作
|
||
|
||
1. 增加数据库迁移目录
|
||
2. 实现 Excel -> ORM 的导入脚本
|
||
3. 先完成 Engine 列表、详情、编辑页
|
||
4. 再补 Communication / Tank / Vehicle Cost 的管理页
|
||
|
||
|