小小大大學

前言： 「我明明在資料庫查不到，為什麼系統畫面卻顯示有？」 這是一個 幾乎所有工程師都一定會遇到 、而且常常讓人懷疑人生的問題。 ❓「資料庫明明沒有這筆資料， ❓ 為什麼系統畫面卻顯示得好好的？」 這篇文章會用 完全不需要程式背景 的方式， 一步一步帶你理解： 為什麼「你看到的畫面」不一定等於「資料庫現在的資料」 常見造成誤判的 5 大原因 工程師實務上如何快速定位問題 一、先講結論（給沒時間的人） 👉 99% 的情況不是資料庫錯，而是「你查的不是同一件事」 最常見的原因包括： 系統畫面與你手動查詢的「條件不一樣」 系統其實連到「不同資料庫或不同環境」 系統畫面顯示的是「快取的舊資料」 欄位是「系統自己組合出來的」，不是資料庫原始欄位 畫面兩個欄位「看起來一樣」，其實是同一個來源 接下來我們一個一個說清楚。 二、為什麼「畫面看到的資料」不一定是資料庫原始資料？ 🧠 用生活比喻來理解 想像你在看 手機銀行 App ： 你看到的是「帳戶餘額」 但實際上 App 可能是： 5 分鐘前同步的 來自備用資料庫 經過系統重新計算後的結果 👉 畫面 ≠ 即時資料庫 企業系統（特別是報表、BI、分析系統）幾乎都這樣設計。 三、常見誤會 1：你查的條件，跟畫面根本不是同一批資料 ❌ 新手最常犯的錯 「我用 A 條件查資料庫， 但畫面用的是 B 條件， 然後說資料不一致。」 👨‍💻 工程師會怎麼想？ 工程師一定會先確認： 產品代碼是否相同？ 製程階段是否相同？ 供應商是否相...

前言：為什麼「終止 bat」這件事很重要？ 在許多公司環境中，Windows 的 批次檔（.bat） 常被用來： 自動執行資料處理 定時跑程式（搭配工作排程） 串接多個工具一次完成工作 但只要其中一個步驟出問題，整支批次檔就可能： 卡住不動 錯誤卻繼續往下跑 背景一直吃資源卻沒人發現 👉 對完全不懂程式的人來說，最常見的困擾就是： 「這個黑色視窗怎麼關都關不掉？」 「它到底有沒有跑完？」  「出錯時可以自己停下來嗎？」 這篇文章，會用 白話 + 工程師實務 一次講清楚。 什麼是 .bat？可以把它想成「自動照流程做事的清單」 你可以把 .bat 想成一張「 電腦照著做的 SOP 清單 」： 先做事情 A 再做事情 B 接著做事情 C 全部做完就結束 每一行都是一個「指令」，電腦會 一行一行照順序做 。 為什麼 bat 會「跑不完」或「停不下來」？ 常見原因包括： 某個步驟在等資料，一直等不到 外部程式卡死但 bat 不知道 沒有告訴 bat：「出錯就要停」 結果就會變成： bat：我還在跑 人：我不知道它在幹嘛 😰 第一種終止方式：人工中斷（任何人都能用） 方法：鍵盤直接中斷 只要看到黑色視窗在跑，按下： Ctrl + C 畫面通常會出現類似： 是否要終止批次工作？ ( Y /N) 輸入 Y ，整個流程就會停止。 適合什麼時候？ 手動測試 發現跑錯 臨時要停 📌 缺點： 不夠安全 不適合自動化或工作排程 第二種方式：讓 bat「自己知道該停」（工程師最常用） 這種方式是 ...

內容 一、你看到的現象其實很典型：BIN 不見、(Empty) 出現、0.00 很多、選兩個 Lot 卻只剩一個 很多人第一次在 Spotfire 做 Yield / BIN 報表會遇到類似狀況： Yield Summary 表格應該要有 BIN1、BIN5、BIN36…，結果完全沒出現 表格或 Pivot 後的欄位出現 (Empty) BIN 欄位很多都顯示 0.00 ，看起來像「資料明明篩掉了 0，怎麼還是 0？」 明明選了兩筆（兩個 Lot），結果最後只剩一筆出現在 Yield Summary 這些問題看似四散，但本質都可以用「資料處理管線」的概念一次理解。 二、先用最簡單的比喻：Spotfire 就像一台「多段加工機」 你可以把整個流程想成： 資料庫（SQL） ：把原料（資料）運進來 Spotfire 的 Join/Pivot ：把原料組裝成你要的形狀 視覺化（Table/Chart） ：把結果畫成表格與圖表 互動（Marking/Filtering） ：你點了圖，其他視覺會跟著變 只要其中一段「加工」做錯，就會出現你看到的怪狀況。 三、最重要的核心：為什麼會出現 (Empty)？ Spotfire 的 Pivot 常見邏輯是： 你指定「分類欄位」當作 Pivot 後的欄名來源 如果那個分類欄位是空的（Null/空字串），Spotfire 就會把它統一歸類成 (Empty) ✅ 直覺理解 你想要欄位叫：BIN1、BIN2、BIN36 但你用來命名的那個欄位是空的 Spotfire 只好產生一個叫 (Empty) ...

  前言： 「資料明明存在，為什麼畫面卻是空的？」 這是一個 所有做過資料分析、BI 報表、或資料視覺化系統的人一定都遇過的問題 ： 👉 同一份資料 👉 同一個操作流程 👉 有時候畫面正常  👉 有時候卻「完全沒有資料」 而且最可怕的是： 沒有錯誤訊息 沒有 Exception 甚至 Debug log 看起來「一切正常」 這篇文章會帶你理解： 為什麼這種問題會發生，以及專業工程師是怎麼把它抓出來的。 一、先把名詞講清楚（給完全沒背景的人） 什麼是「Bin」？ 在很多測試或分類系統中，我們會把結果分成不同類別，例如： 類別編號 意義 Bin 1 通過 Bin 5 輕微異常 Bin 19 嚴重異常 工程師習慣把這些稱為 Bin（分類桶） 。 那為什麼會「沒有 Bin」？ 因為在一個完整系統中， 同一個 Bin，會用「不同方式表示」 。 舉例來說，下面這些其實「人類看起來一樣」，但 電腦完全不覺得一樣 ： 人類理解 系統實際字串 Bin 1 "1" Bin 1 "BIN1" Bin 1 "BIN 1" Bin 1 "01" Bin 1 "Bin01" 👉 電腦比對時是「逐字元完全相等」 只要有一個空白、一個前綴，結果就會不同。 二、問題的真相： Bug 不是資料錯，而是「工程假設錯」 這次案例的核心問題可以用一句話總結： ❌ 系統用「顯示用的字串」來當「資料比對的依據」 這在工程上是 非常危險的設計 。 三、系統中實際發生了什麼事？（白話版） 我們來拆解一個常見的資料流程： 原始資料 ↓ 整理 / 合併 ↓ 分類（Bin） ↓ 轉成報表用格式 ↓ 顯示在畫面 問題發生在這裡 👇 ❌ 錯誤流程（很多系統都這樣做） 使用者選擇「我要看 Bin1、Bin5、Bin19」 系統拿「畫面上看到的字串」去比對資料 發現「怎麼都對不到」 系統很認真地把資料「全部刪掉」 畫面顯示： 沒有 Bin 但其實資料根本沒消失。 四、專業工程師怎麼 Debug 這種問題？ Step 1：先不要猜，直接「印出來看」 第一件事永遠是： 👉 把...

  適合讀者 ： 剛接手 Spotfire 專案的新手 看到一堆表名（RAW_xxx、ASMT_xxx）卻不知道資料從哪來的人 工程師 / 分析師 / BI 使用者 常被問：「這張圖的數字是哪來的？」卻答不出來的人 一句話先講結論（給忙的人） 在 TIBCO Spotfire 裡： 畫面上的結果 ≠ 程式碼直接算出來的 大多數情況是：  SQL 資料庫 → Spotfire Data Table → Data Function 處理 → 圖表顯示 只要你能一路回推這條鏈，就一定能找到「真正的資料來源」。 一、為什麼 Spotfire 會讓人「找不到資料來源」？ 很多人第一次看 Spotfire，會遇到這種情況： 畫面上有一張表，例如： 👉 FT_YIELD_BIN 打開屬性只看到： 👉 Source function: 某個 Python Data Function 再看 Data Function，只看到一個名字： 👉 ft_yield 然後就卡住了 😵 心裡只剩下一句話： 「所以資料到底從哪來？」 二、Spotfire 的資料其實有「三層結構」 用白話說，Spotfire 的資料來源通常分三層： 第 1 層：資料庫（最底層） SQL Server / Oracle / MySQL… 真正存資料的地方 例如某個 Yield、測試、製程資料表 第 2 層：Spotfire Data Table 用 SQL 把資料撈進 Spotfire 表名常長這樣： RAW_xxx ASMT_xxx TMP_xxx 第 3 層：Data Function / Script Python / R 對 Data Table 做「再加工」 例如加總、轉換、比例計算 👉 很多人卡住，是因為只看到第 3 層 三、ft_yield 是什麼？（重點釐清） ft_yield 不是一張表 ，也不是 SQL。 它是： Data Function 的「輸入參數名稱」 白話翻譯就是： 「我這段 Python，需要你給我一批資料欄位來算」 而這批資料，實際上來自 另一張 Spotf...

一、問題背景： 「明明資料庫有資料，為什麼報表就是不顯示？」 很多人在第一次接觸資料分析工具（例如 BI 報表系統）時，都會遇到一個非常挫折的情況： ✅ SQL 查得到資料 ✅ 表格中也有數字  ❌ 但圖表、報表中的「分類欄位」卻完全不見了 尤其是像 Bin / 類別 / 分群 這種欄位，常常「消失得無聲無息」。 這篇文章會用 完全不需要程式背景 的方式，帶你一步一步理解： 問題到底出在哪 為什麼系統不會主動告訴你錯在哪 工程師是怎麼判斷並修掉它的 二、先用生活比喻理解「Bin 為什麼不見」 想像你在做一張「考試成績分析表」： 學生 分數 小明 85 小華 92 接著你想把成績分成： A：90 分以上 B：80–89 分 C：70–79 分 👉 這個「A / B / C」就像報表裡的 Bin 但如果發生以下情況會怎樣？ 一張表用的是「分數是數字」 另一張表卻用的是「A、B、C 是文字」 系統被要求「用數字去對文字做對照」 📛 結果：全部對不起來，但系統也不會報錯 三、工程師實際遇到的核心問題（白話版） ❌ 問題不是「沒有資料」，而是「資料對不上」 在實際系統中，工程師發現： 系統確實有「Bin 的數量」 但用來顯示名稱的資料表，格式卻不一致 例如（示意）： 表 A（主資料） 表 B（對照表） ...

前言：為什麼「欄位改了」會讓系統出問題？ 在企業系統中，常常會遇到這樣的情況： 原本每天正常匯入資料 某一天因為需求變更， 輸入檔案的欄位或規則被調整 新進資料看起來正常 但舊資料卻顯示錯誤或空白 報表、BI、分析結果開始不一致 這時候很多人會直覺認為： 「我已經把程式改好了，為什麼舊資料沒變？」 這篇文章會用 不需要工程背景 的方式，完整解釋原因與正確做法。 一、什麼是 Loader？用白話講就是「資料搬運工」 你可以把 Loader 想像成一個自動化工人： 從資料夾讀取檔案（例如 CSV、彙總檔） 把檔案內容轉成資料庫可以存的格式 寫入多張資料表 成功就把檔案移到「成功資料夾」 失敗就移到「失敗資料夾」 同時留下「處理紀錄」，方便之後追蹤 重點是： Loader 的主要任務是「處理新資料」，不是「修改舊資料」。 二、Loader 是怎麼分辨 FT1Y 與其他站點的？ 很多人會以為程式裡有這種判斷： 「如果是 FT1Y，就做不一樣的事」 實務上其實不是。 真正的做法是： Loader 會從 檔名或檔案內容 中解析出一個「站點代碼」 例如：FT1、FT1Y、RT1、FT2 這個站點代碼會被存成一個欄位（例如：OP_NAME） 之後所有判斷、查詢、報表，都是靠這個欄位來區分 換句話說： 對 Loader 而言，FT1Y 只是「一個值」，不是「一段特殊程式」 三、為什麼「改了程式」卻修不好舊資料？ 這是整個問題的核心。 Loader 的基本設計邏輯是： 第一次看到的資料 → 建立新紀錄 已存在的資料 → 只更新統...