🧾【工程師教學】為什麼資料庫的 Product No 會是空的？從 Loader 設計一次搞懂 FT1Y 的資料來源

- 1月 22, 2026

前言：為什麼「Product No 是空值」會變成大問題？

在製造或測試相關系統中，
Product No（產品型號） 幾乎是所有報表、查詢、分析的核心欄位。

但在實務上，工程師常會遇到一個狀況：

📌
明明 Excel 裡有「型號」，
但進到資料庫後，
Product No 卻是 NULL（空值）

這篇文章會用完全不需要懂原始程式碼的方式，
一步一步帶你理解：

資料是怎麼從 Excel 進資料庫的？
為什麼只有 FT1Y 會出問題？
工程師真正該改的是「哪一層邏輯」？

一、先搞懂系統角色（不看程式也能懂）

我們先把系統拆成三個角色：

1️⃣ Excel（資料來源）

使用者提供的檔案
裡面有欄位，例如：
- 型號
- 批號
- 時間
- 測試站別

Excel 不會直接寫進資料庫。

2️⃣ Loader（資料搬運員）

Loader 的工作只有一件事：

「把 Excel 的資料，轉成資料庫看得懂的格式」

它會做三件事：

讀 Excel 的每一列
把欄位塞進「暫存物件」
再由這個物件寫進資料庫

3️⃣ 資料庫（最終存放地）

例如：

欄位名稱	用途
PRODUCT_ID	產品代碼
PART_ID	產品型號（Product No）
OP_NAME	製程站別

二、問題真正發生在哪？

❓ 為什麼 Excel 有「型號」，但資料庫沒有？

關鍵原因只有一句話：

Loader 沒有把 Excel 的「型號」，放進 PART_ID 欄位

不是資料庫錯，也不是 Excel 錯。

三、Loader 裡發生了什麼事？（白話版）

Loader 的邏輯大概是這樣（示意）


讀取 Excel 的一列 →
建立一個 Lot 物件 →
把 Lot 物件寫進資料庫

這個「Lot 物件」裡，有很多屬性，例如：


lot.productCode
lot.partNumber
lot.operationName

但問題來了👇

Loader 只設定了：


lot.productCode ← Excel 的「型號」

卻 沒有設定：


lot.partNumber ← Excel 的「型號」

結果就是：

資料庫的 PRODUCT_ID 有值
資料庫的 PART_ID 是空的

四、為什麼「只有 FT1Y」需要特別處理？

關鍵觀念：不是 Excel 判斷 FT1Y

而是：

Loader 本身就被設計成「專門處理 FT1Y」

在系統架構中：

每一種製程站別（OP_NAME）
都有自己對應的 Loader

所以：


只要走 FT1Y Loader
→ 系統就「預設這是 FT1Y」

五、工程師真正該改的地方是哪裡？

❌ 錯誤做法（常見誤會）

改 SQL
改報表
改資料庫欄位

👉 這些都「太後面了」

✅ 正確做法（一次解決）

在 Loader 讀 Excel 的地方，補上這個對應關係：

示意邏輯（非實際程式碼）


如果目前處理的是 FT1Y：
    將 Excel 的「型號」
    同時指定給：
        - Product ID
        - Part ID

也就是：

Excel 欄位	寫入欄位
型號	PRODUCT_ID
型號	PART_ID（僅 FT1Y）

六、為什麼這樣改「最安全」？

因為：

✔ 只影響 FT1Y
✔ 其他站別完全不動
✔ 不影響歷史資料
✔ 不需要改資料庫結構
✔ 報表自動就正常

七、改完後要怎麼驗證？（新手也能做）

工程師通常會跑一個確認查詢：


查看最近的 FT1Y 資料
確認 Product No 是否已經有值

如果：

PRODUCT_ID 有值
PART_ID 也有值

👉 表示 Loader 修正成功 🎉

八、這個案例給工程師的三個重點教訓

✅ 1. 資料問題，通常不是 SQL 的錯

而是「上游沒有塞資料」

✅ 2. Loader 是最關鍵、也最容易被忽略的一層

很多人只看：

Excel
DB

卻忽略中間的「轉換邏輯」

✅ 3. 一個 Loader，通常只對應一種業務規則

不要假設：

「同一支程式，會處理所有情況」

結語：為什麼工程師一定要懂資料流？

這類問題如果只用「修 SQL」的方式處理，
只會一修再修、永遠修不完。

真正專業的工程師，會先問三件事：

資料從哪來？
中間經過誰？
是在哪一層被丟掉？

只要掌握這個思維，
90% 的資料異常問題都能一次解決。

搜尋此網誌

小小大大學