《#061 PM 不用會寫程式碼，但要懂的技術架構》 我們把前端、後端、API 的分工講清楚了，接下來 RD 進到另一個更現實的問題。資料要怎麼存，怎麼拿，怎麼關聯。你如果腦中只有畫面與流程，沒有資料結構，規格就會看起來很完整，實作時卻處處卡住，最後變成兩種結果。第一種是「存得進去，但拿不出來」。第二種是「勉強拿得出來，但成本高到不合理」。
更麻煩的是，資料問題通常不是上線當天才爆，它會以一種很陰險的方式累積。前期你覺得還可以，資料量一大、需求一多、報表一來，你才發現自己當初寫的每一句「應該可以吧」，都要用開發時間、維運成本、效能退化去付利息。
這篇先用三個常見事故聊聊，讓你知道「不懂資料和資料庫」會長成什麼樣子，再回到 Table、Key、ER Model 這套 PM 必須能溝通的基本語言。
◆ 事故一 「1234567」你以為是數字，其實它更可能是文字
「1234567」看起來像數字，很多人就順手寫成 number。問題是，資料庫裡的「數字」不只是長得像數字，它會被拿去做運算、排序、四捨五入、格式轉換。只要你的欄位本質不是「可計算的量」，把它存成數字，就很容易出事。
幾個你一定看過的狀況。電話號碼最常中槍，因為它會有「0 開頭」、會有國碼、會有分機。你把它當數字存，前面的 0 可能直接消失，報表還會把它印成科學記號。郵遞區號、身分證號、統編、訂單編號也一樣，它們是識別碼，不是用來加減乘除的量。再往下走，像是「0012」這種等級或序號，一旦被當數字，前導零被吃掉，你後面就會開始補救格式，補到最後變成全系統都在跟格式打架。
更細的坑是「看起來是數字，但規則不是數學」。金額要不要小數點、要不要固定兩位、幣別不同怎麼處理。日期時間要不要時區、要不要只存日期、要不要存到秒或毫秒。真假值要不要用布林值，還是用狀態碼。這些如果一開始沒有寫清楚，資料可以先放進去，但你之後會在查詢、報表、匯出、跨系統串接時被反覆提醒。
這也是為什麼規格書除了畫面與流程，還需要一份很務實的附件。資料字典。欄位名稱、型態、長度、是否必填、允許值範圍、預設值、範例值、驗證規則。它不華麗，但它能避免「大家都以為懂了」的誤會。
◆ 事故二 資料表不是一直加欄位就會變靈活，通常只會越來越難維護
第二種事故很常發生在「客戶想客製」的產品。A 客戶要 4 個指定欄位，B 客戶要 8 個，C 客戶要 5 個。你如果用最直覺的方式處理，就是一直往同一張表加欄位。短期看起來有效，長期會變成三個問題一起來。
第一個問題是共用性崩壞。同一個概念被不同客戶用不同欄位表達，你的報表與搜尋會越做越痛苦，因為你根本不知道該查哪一個欄位才算「這個意思」。第二個問題是可擴充性變差。每加一次欄位就要改資料庫、改 API、改表單、改驗證、改匯出格式。客戶越多，你改一次越像在拆炸彈。第三個問題是好管理性消失。大量空值、欄位命名混亂、權限與稽核難以一致，最後會變成系統看起來什麼都能放，但大家都找不到「該放哪」。
比較成熟的做法不是硬把所有差異塞進同一張表，而是回到兩個判斷。哪些是「大家都會有」的核心資料，哪些是「每家不一定一樣」的延伸資料。核心資料放核心表，延伸資料用延伸結構處理，例如獨立的自訂欄位表、屬性表，或是在可控的範圍內用結構化欄位承接。每一種做法都有成本與取捨，但重點在於你要能把「變動」放在可管理的位置，而不是把所有變動散落在一堆欄位裡。
PM 在這裡需要做到的，不是設計資料庫技巧，而是把需求問清楚。這些欄位到底是「顯示給人看」還是「要拿來搜尋與統計」。要不要支援匯出與報表。要不要權限控管。要不要稽核變更紀錄。你一旦把這些用途寫進規格，RD 才能選到合理的資料結構，而不是用最省事、但最容易後悔的方式先做下去。
◆ 事故三 動態資料一直長大，沒有保留與清理策略，效能會一路往下
第三種事故通常不是當下爆炸，而是慢慢把系統拖垮。像是 log、交易紀錄、操作紀錄、通知紀錄 這類資料，會持續產生，而且幾乎不會停止。相對地，像是商品資料、方案設定、權限角色、系統參數，這些多半是設定完就很少變動的靜態資料。
動態資料的麻煩在於，它不是「要不要存」的問題，而是「存了之後怎麼管理」。你要想的是備份、保留期限、封存、清理。如果這些沒有先定義，資料量只會一直上升，索引膨脹、查詢變慢、備份時間拉長、恢復時間變長。到某個時間點，你連做一個簡單的列表頁，都會開始卡，營運同事會覺得系統不穩，RD 會覺得每次查問題都像在挖礦。
更現實的是，很多資料其實不需要永久留在主資料庫。交易紀錄需要法規或稽核，就要明確保留年限。操作紀錄可能只需要近 90 天用來追查問題，過了就可以轉存到較低成本的儲存或做彙整。這些政策如果一開始沒有寫進規格，後面再補，往往就會變成一個成本很高的大工程。
◆ Excel 與 Database 的差異，不是工具不同，是世界觀不同
很多 PM 用 Excel 做過資料整理，所以會不自覺把資料庫想成「更大的 Excel」。這是誤解的起點。Excel 的世界是平面的，一列就是一筆，一欄就是一個值，重複也沒關係，手動整理就好。資料庫是關聯式世界，它更在意的是資料之間的關係與一致性。你不是把資料放進去而已，你是在定義資料未來怎麼被查詢、怎麼被串接、怎麼被維護。當 PM 用 Excel 思維寫規格，很容易把「可視化的表格」當成「可運作的資料」，兩者差距通常要到報表對不起來、資料改不動時才被迫承認。
當 RD 問你「這是一對一還是一對多，要不要做關聯」，他其實在問，你要讓資料以什麼方式被維持、被查詢、被延伸。
◆ Table 與 Key。每筆資料都需要「可被辨識」的方式
資料庫裡每一筆資料都需要身分，否則後續的更新、查詢、關聯都缺少落點。Key 的概念就是替資料建立可被辨識的方式，不只是主鍵，也包含外鍵與各種唯一識別。這不只是技術要求，對 PM 來說，它代表你能不能明確說出「這一筆資料」是什麼，以及它跟別的資料怎麼對上。很多「看起來能存」的設計，最後會在這裡破功，因為你沒有一個穩定的辨識方式，資料只能新增不能修正，或是修正時動到錯的那筆。
Table 是同類型資料的集合，例如使用者表、訂單表、商品表。問題在於，表裡每一筆資料必須能被清楚辨識，否則你無法更新、無法引用、無法關聯。這就是 主鍵 Primary Key 的角色。它通常是一個唯一值，用來代表這一筆資料的身分。
接著你會遇到另一個必備概念。外鍵 Foreign Key。當一筆訂單屬於某個使用者，訂單表裡就需要有一個欄位指向使用者的主鍵。這種「指向」就是關聯的實體化。你如果沒有這種關聯，資料仍然可以存，但你會在查詢時吃盡苦頭，也更容易出現資料對不起來的狀況。
◆ ER Model。不是畫圖交作業，是把資料關係講清楚
ER Model 的價值不在圖畫得多漂亮，而在於你能不能把關係講清楚。一對一、一對多、多對多的差別，對 PM 來說等同於功能是否能成立。例如一個使用者能不能有多個訂單，或是一筆訂單能不能包含多個商品。你如果把多對多用「一堆欄位」硬塞進同一張表，短期或許能跑，長期會在查詢、統計、擴充時付出代價。ER Model 是讓你在開規格時先把資料的互動方式定義出來，而不是讓資料表在開發中期才臨時改造。
ER Model 的核心是兩件事。實體 Entity 與 關係 Relationship。實體就是你的資料角色，例如使用者、訂單、商品。關係則是它們之間怎麼連動。
三種關係要能說清楚，規格才不會「寫得很順，做起來很痛苦」。
一對一 1 對 1
一個人對一張身分資料。或是一個使用者對一份設定檔。這類關係通常是資料拆分與權限考量，或是把不常用欄位獨立出去。
一對多 1 對多
一個使用者可以有多張訂單。這是最常見、也最容易理解的關係。你在規格裡至少要能回答，使用者刪除後，訂單要怎麼處理。要保留還是連動刪除。這不是細節，它會直接影響實作與稽核。
多對多 多對多
一張訂單可以有多個商品，一個商品也可以出現在多張訂單裡。這種關係在資料庫裡通常需要一張「中介表」，例如訂單明細表，裡面放訂單與商品的對應，還會放數量、價格、折扣等與「這次購買」相關的欄位。很多「存得進去拿不出來」的規格，都是卡在這裡，因為你把一個多對多硬塞成一張表的多欄位，最後查詢與維護都會變得混亂。
◆ 正規化（Normalization）。不是學術名詞，是避免「資料自相矛盾」的生活常識
很多PM第一次聽到「正規化」，腦中都是一片空白，想說「這是火星話」嗎？
正規化的核心很實際，一個事實盡量只出現在一個地方，同一件事情不要在不同表、不同欄位以不同形式重複出現。重複一多，更新就會失真，報表就會矛盾，最後你會遇到最難修的問題之一，同一個使用者在不同畫面顯示不同資料，誰都說不清楚哪一個才是正確版本。正規化不是要 PM 背定義，它要你在寫需求時先想到一件事，資料的可維護性通常比一次性存進去更重要。
其實「正規化」並不可怕，是可以幫助PM很好用的工具：
- 一個欄位只放一種事實
不要把「電話＋分機」塞進同一格，也不要把「狀態＋原因」混在一起。你一旦需要拆解或統計，就會陷入痛苦。 - 同一份資訊只放在一個地方
商品名稱、客戶名稱、方案內容這種「主資料」，應該有自己的表。訂單只存product_id，不要把商品名稱再抄一次。否則商品改名那天，你永遠改不完。 - 把會變的、會長的、會爆的分開
靜態資料（商品、方案、角色）跟動態資料（交易、操作紀錄、log）放在同一張表，通常只會讓查詢越來越慢，也讓維運越來越不穩。
你不需要用「正規化」去證明自己專業，你要用它去回答一個很實際的問題：
這份資料未來要不要被更新、被引用、被統計、被稽核？如果要，那就不能用「先存起來再說」的方式處理。
當你有辦法和技術團隊討論資料的時候，說出「正規化」的概念時，大多數的工程師基本上會默默地認同你是一名專業的技術型PM。
◆ 四個觀念，對應三種事故。不是加規則，是把風險先分層
前面那三種災難，看起來像三個不同問題，但本質很一致，資料在一開始沒有被定義清楚。一旦資料沒有被定義，後面就只剩下「先存進去再說」。短期或許看似有進展，長期則會在維護、擴充、報表與效能上，把代價逐步補回來。
因此，這一篇的四個觀念，其實是在替 PM 提供一套分層思考的方法，讓你在寫規格時能先判斷風險落在哪一層，接著再決定要用哪一種資料結構解法去承接。
如何應對事故一 「1234567」看起來是數字，其實可能是文字
這類問題表面上是格式錯誤，真正的風險是你以為能算、能比、能排序，結果全都不成立。例如帳號、統編、郵遞區號、訂單編號，雖然外觀由數字組成，但它們的角色通常是辨識，不是運算。一旦把它當成數字處理，就容易發生前導零消失、顯示變形、排序失真等狀況，最後又回到使用者端的混亂與不信任。
這一題最直接會用到的，是 Table 與 Key 的觀念。因為 Key 的目的就是可被辨識與引用，而不是可被運算。只要你先把欄位角色講清楚，資料型態的選擇就會自然收斂。同時，Excel 與 Database 的差異也會在這裡出現。Excel 容許「看起來像」就先過關，資料庫要的是可驗證。你需要描述的不是外觀，而是這筆資料在系統裡要被拿去做什麼。
接著才是 ER Model 與正規化的介入。ER Model 的價值在於協助你辨識這到底是屬性，還是關係。例如電話、地址、聯絡方式，常常不是單一欄位就能承接的資料。當你把多個事實塞進同一格，後續查詢與統計幾乎必然失真。正規化的提醒則更直接，一個欄位放一種事實，同一件事不要在不同地方以不同形式重複出現。型態一旦清楚，錯誤就能在資料入口被攔下來，而不是拖到上線後才暴露。
如何應對事故二 最後只剩下無止盡加欄位
這類問題常被誤判成需求不清楚，但更精準的說法是資料的共用性與擴充方式沒有先定義。當你用「每個客戶想要什麼就加什麼欄位」的方式延伸，短期看似滿足需求，長期會遇到三個現實代價。第一，欄位大量空值化，資料表難以閱讀。第二，同義欄位逐步分裂，報表開始對不起來。第三，每一次新客戶上線都牽動資料表結構，開發與維護成本被迫持續上升。
這一題真正要依靠的，是正規化與 ER Model 的組合。正規化要你先把共通欄位與可變欄位分離，避免把差異散落在一堆欄位裡。ER Model 則把關係講清楚，例如一個客戶有多個自訂欄位值這種典型的一對多關係。當關係先被說清楚，你就有機會把可變部分放到獨立結構中，透過 Key 進行引用，而不是讓主表無限制膨脹。
此時 Table 與 Key 的角色會更關鍵。因為可變欄位不只是存得進去，還涉及怎麼管理。例如欄位名稱、資料型態、驗證規則、是否可搜尋、是否可用於報表，這些都需要可被辨識的方式，才能避免後續只剩下人工記憶與口耳相傳。
換句話說，這一題不是在討論要不要加欄位，而是在討論你打算用什麼結構承接差異。有結構，才有管理。沒有結構，就只剩下堆疊。
如何應對事故三 log、交易紀錄持續累積，效能隨時間下降
這類問題最常被忽略，原因很簡單，它不是現在就壞，而是逐步變慢。但一旦慢到影響使用者，回頭修復的代價往往遠高於一開始就做基本規劃。
這一題首先牽涉到 Excel 與 Database 的世界觀差異。Excel 的直覺是一直往下加，資料庫若沒有策略，也會一直增加，但資料庫面對的不是畫面變長，而是索引膨脹、查詢時間拉長、備份與復原成本上升。因此，這裡需要的不是一句「要備份」，而是資料生命週期的描述，保留多久、多久後封存、封存位置、清理策略、稽核需求是否需要跨封存查詢。
接著是 Table 與 Key 的基本盤。動態資料必須可追溯，但不代表要永久停留在同一個熱區。只要 Key 與時間欄位設計得足以支援追查與分區，後續的封存與分表策略就會有落點，而不必重新發明一套追溯方式。
最後是 ER Model 與正規化。ER Model 協助你避免把所有紀錄塞進一張萬用大表，讓不同用途的紀錄有合理邊界。正規化則避免資料因為重複存放而無限制膨脹，並促使你把主資料與歷史資料分離，使系統能在長期運作下維持可控的效能曲線。
◆ 四個觀念的價值，在於讓 PM 能在規劃需求時想像資料怎麼運作
資料會讓 PM 投降，多半不是因為不努力，而是因為資料的運作過於抽象。畫面可以用眼睛看，流程可以用故事講，資料卻像在黑盒子裡，沒有模型就難以描述。這一篇的四個觀念，就是把黑盒子拆成 PM 能掌握的四個層次。
你先用 Excel 與 Database 的差異換掉直覺，避免用平面表格想像關聯資料。你再用 Table 與 Key 讓資料可被辨識與引用，讓更新、關聯、追溯都有依據。你用 ER Model 把關係說清楚，避免把關係藏在一堆欄位或一堆例外規則裡。你用正規化減少重複與矛盾，讓資料在擴充與維護上仍保有秩序。
當 PM 能在需求階段就把資料怎麼被建立、怎麼被引用、怎麼被查詢、怎麼被維護想像出來，規格就不會只停留在畫面與流程，而是開始具備可落地的資料結構與資料使用方式。這也是 PM 在產品進入開發後，真正能降低溝通成本與返工風險的位置。你不需要成為資料庫工程師，但你需要有一套能把資料講清楚的語言，否則投降會變成常態，代價則會在產品後半段慢慢累積回來。
◆ 廣三觀點
嗨，我是廣三。PM 不需要背資料庫名詞，但至少要能在規格階段把三件事說明白。資料型態要清楚，避免把識別碼當成數字去存。資料結構要能延伸，避免用一直加欄位的方式消耗未來。資料生命週期要有規劃，避免動態資料把系統效能與維運節奏慢慢拖垮。
你會發現，資料問題最討厭的地方，不在技術，而在它很容易被忽略，直到某天你才突然被迫面對。把 Table、Key、ER Model 放進你的規格語言裡，你就不會再把資料庫當成「可以先放著」的事情。產品能不能穩定長期運作，很多時候就是在這些看似不起眼的欄位與關聯上決定的。
若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。
歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi
《歡迎加我LINE，一起破局未來》
請於下方輸入電子郵件信箱，即可接收最新訊息。
留言