🍀Loader 欄位改了怎麼辦?用最安全的方法修正資料庫歷史資料(給非工程背景也看得懂的完整教學)

前言:為什麼「欄位改了」會讓系統出問題?

在企業系統中,常常會遇到這樣的情況:

  • 原本每天正常匯入資料

  • 某一天因為需求變更,輸入檔案的欄位或規則被調整

  • 新進資料看起來正常

  • 但舊資料卻顯示錯誤或空白

  • 報表、BI、分析結果開始不一致

這時候很多人會直覺認為:

「我已經把程式改好了,為什麼舊資料沒變?」

這篇文章會用不需要工程背景的方式,完整解釋原因與正確做法。


一、什麼是 Loader?用白話講就是「資料搬運工」

你可以把 Loader 想像成一個自動化工人:

  1. 從資料夾讀取檔案(例如 CSV、彙總檔)

  2. 把檔案內容轉成資料庫可以存的格式

  3. 寫入多張資料表

  4. 成功就把檔案移到「成功資料夾」

  5. 失敗就移到「失敗資料夾」

  6. 同時留下「處理紀錄」,方便之後追蹤

重點是:
Loader 的主要任務是「處理新資料」,不是「修改舊資料」。


二、Loader 是怎麼分辨 FT1Y 與其他站點的?

很多人會以為程式裡有這種判斷:

「如果是 FT1Y,就做不一樣的事」


實務上其實不是。

真正的做法是:

  • Loader 會從檔名或檔案內容中解析出一個「站點代碼」

  • 例如:FT1、FT1Y、RT1、FT2

  • 這個站點代碼會被存成一個欄位(例如:OP_NAME)

  • 之後所有判斷、查詢、報表,都是靠這個欄位來區分

換句話說:

對 Loader 而言,FT1Y 只是「一個值」,不是「一段特殊程式」



三、為什麼「改了程式」卻修不好舊資料?

這是整個問題的核心。

Loader 的基本設計邏輯是:

  • 第一次看到的資料 → 建立新紀錄

  • 已存在的資料 → 只更新統計結果,不重寫欄位

也就是說:

  • 程式邏輯改動後

  • 只會影響未來新進的資料

  • 歷史資料會維持「當初寫進去時的樣子」

所以就會出現:

資料時間 欄位內容
舊資料 空白 / 舊規則
新資料 新規則

這不是 Bug,而是設計本來就如此。


四、歷史資料要怎麼修?只有兩種正確做法

方法一:使用 SQL UPDATE 回補歷史資料(最常見、最安全)

適合情況:

  • 欄位意義沒有變,只是來源改了

  • 舊資料只是「沒填到」

  • 不想影響整個資料庫

概念範例(匿名、非實際程式碼):

「如果欄位 A 是空的,就用欄位 B 補上」

實務上一定會先查詢、確認影響範圍,再執行更新。

優點

  • 速度快

  • 風險低

  • 可只修特定站點(例如 FT1Y)

缺點

  • 需要確定邏輯正確


方法二:刪除資料表後重新 Loader(最乾淨、但風險高)

適合情況:

  • 欄位定義大改

  • 舊資料整批都不可信

  • 可以接受重新產生所有資料

當你:

  • 刪掉資料表

  • 再用最新程式重新跑 Loader

那麼:

所有資料都會完全依照新規則產生

這種情況下,通常 不需要再做 SQL 更新

⚠️ 但要注意:

  • 索引是否重建

  • 權限是否恢復

  • 其他系統是否依賴該資料表


五、兩個最常見、也最容易踩的技術地雷

地雷一:SQL 引號錯誤

有些文字編輯器會把 ' 自動變成「智慧引號」,
看起來一樣,但資料庫其實無法解析。

解法:

  • 在資料庫工具中手動輸入半形引號

  • 不要直接從文件或聊天工具貼上


地雷二:Python 縮排錯誤(IndentationError)

Python 非常嚴格,只要:

  • Tab 與空白混用

  • 縮排層級不一致

程式就會直接無法執行,連資料庫都還沒碰到。

解法:

  1. 使用專業編輯器(VS Code、Notepad++)

  2. 統一縮排為 4 個空白

  3. 整個函式區塊重新排版

  4. 先做語法檢查再執行


六、怎麼確認 Loader 真的有把資料寫進資料庫?

不需要懂程式,只要看三件事:

  1. 處理紀錄有新增

  2. 檔案被移到成功資料夾

  3. 資料庫中的筆數或時間有更新

如果三者都有,通常代表 Loader 正常運作。


七、工程師最推薦的標準作業流程(SOP)

記住這一句就好:

程式改未來,SQL 修過去。

實務 SOP:

  1. 修正 Loader 程式(確保新資料正確)

  2. 確認 Loader 可正常執行

  3. 決定是否需要讓舊資料一致

  4. 若需要:

    • 優先用 SQL UPDATE

    • 最後手段才是刪表重跑


FAQ(常見問題)

Q1:為什麼我已經改程式,歷史資料還是錯?

因為 Loader 不會主動重寫已存在的資料。

Q2:我一定要修歷史資料嗎?

不一定,取決於報表、分析是否需要新舊一致。

Q3:刪表重跑一定比較好嗎?

不一定,風險與影響面較大,需審慎評估。

Q4:縮排錯誤跟資料庫有關嗎?

沒有,是程式語法層級的問題。


結語:真正重要的是「資料一致性策略」

系統穩不穩定,往往不是程式寫得好不好,
而是面對規則變更時,有沒有一套清楚的處理策略

只要記住:

  • Loader 管新資料

  • SQL 管舊資料

  • 不混在一起處理

你的資料系統就能長期穩定運作。

留言

這個網誌中的熱門文章

🔍Vue.js 專案錯誤排查:解決 numericFields is not defined 與合併儲存格邏輯最佳化

🖥️遠端桌面連線完整新手指南:Windows RDP、Chrome Remote Desktop、AnyDesk、TeamViewer 一次搞懂

🔎EF Core 連 Oracle 出現 ORA-00600 [kpp_concatq:2] 的完整排錯指南(含 EF Core ToString/CultureInfo 錯誤)