# 项目梳理（第一轮）

## 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 导入脚本