Day 11：Relation Manager，訂單明細這種巢狀資料怎麼管理 結尾留下一句話，客戶、訂單、訂單明細、商品之間的關聯，技術上都已經打通，訂單知道自己屬於哪個客戶，也知道自己底下有哪些明細，明細知道自己對應哪個商品。可是這幾個 Resource 目前還是分別各自打開才看得到彼此的關聯，還沒有一個地方能讓人一次感受到這整套後台是串在一起運作的系統。

今天要處理的正是這件事，也是第三階段「資料關聯」的最後一天。

四個元件各自整齊，卻沒有一條看得見的線

打開客戶 Resource，看到的是店名、聯絡人、聯絡電話、所屬地區這四個欄位，整整齊齊排在表格裡，但完全看不出這個客戶下過哪些訂單。切換到商品 Resource，一樣是七個欄位規規矩矩地呈現，名稱、規格描述、價格、庫存數量、分類、上架狀態、進貨日期，卻看不出這個商品曾經出現在哪一張訂單裡。訂單 Resource 稍微好一點，列表上能看到客戶名稱，編輯頁裡也能管理訂單明細，但商品跟客戶依然只活在自己的畫面裡，彼此看不見對方。

這四個 Resource 更像是擺在同一個後台選單裡的四個抽屜，每個抽屜裡的東西都整理得很整齊，商品抽屜裡的商品排得清清楚楚，客戶抽屜裡的客戶也一樣。

但抽屜跟抽屜之間，沒有任何一條看得見的線。

這不是哪一天做錯了什麼，Day 9 到 Day 11 各自解決的是不同層次的技術問題，表單怎麼選關聯資料、表格怎麼呈現關聯資料、巢狀資料怎麼獨立管理，每個問題單獨看都已經解決得很乾淨。只是這幾天的節奏是逐一擊破單個技術點，還沒有人帶著讀者從頭到尾走一次一個真實的下單流程，看看這幾個機制擺在一起運作時，究竟是不是真的通的。

今天不新增任何模組或欄位，商品、客戶、訂單、訂單明細的欄位定義完全沿用前面幾天已經定案的內容。

要做的事情是把 Day 9 定案的表單關聯欄位、Day 10 定案的表格關聯呈現、Day 11 定案的 Relation Manager，實際組合成一次完整的業務操作流程，流程走完之後，回頭具體回顧這個階段四天的進度。

走一次真實下單流程，從選客戶到看見明細

假設旺旺寵物用品行今天要叫貨，業務人員要在後台建一張新訂單。

第一步打開訂單的建立頁，填入訂單編號、訂單日期、訂單狀態。

接著是所屬客戶這個欄位，點開下拉選單，打幾個字搜尋，選中「旺旺寵物用品行」。這一步用的正是 Day 09：表單裡選關聯資料，下拉選單背後在做什麼 定案的關聯欄位機制，選單裡看到的是店名，實際存進 customer_id 這個外鍵欄位的，是這間店在客戶資料表裡的主鍵。

畫面上沒有任何跡象顯示這背後正在查詢另一張資料表，對業務人員來說，這就是選了一個客戶而已，複雜的部分早就被 Filament 藏在背後。

儲存這筆訂單，進入編輯頁，訂單自身的欄位下方，商品明細這個獨立區塊已經在等著。這邊是 Day 11：Relation Manager，訂單明細這種巢狀資料怎麼管理 定案的 Relation Manager 上場的時刻。

點擊新增按鈕，選擇商品，第一筆選飼料，數量填十；再點一次新增，第二筆選玩具，數量填五。

旺旺寵物用品行這次叫貨同時訂了兩個品項，這正是 Day 01：為什麼是 Filament，跟手刻後台與其他套件比起來差在哪 定案的業務語意，一間寵物用品店叫貨通常不會只叫一種東西，今天這個流程第一次讓這句業務語意真的在畫面上發生。

兩筆明細都存好之後，這張訂單底下同時掛著飼料跟玩具，各自的數量互不影響，新增第二筆明細的時候，第一筆明細也沒有被打斷或清空，這正是 Day 11 強調過的獨立子介面特性，訂單自身的表單有沒有被修改，跟明細區塊的增刪操作，是兩件互不干擾的事。

回到訂單列表頁，剛才建立的這張訂單，客戶欄位直接顯示「旺旺寵物用品行」，不是一串看不懂的主鍵數字。這一步呼應 Day 10：表格裡顯示關聯資料，一眼看出這張訂單屬於哪個客戶 定案的表格關聯呈現，customer.name 這個寫法早在昨天之前的階段就已經接好，今天只是第一次真的靠它認出這張新訂單。順手點開依客戶篩選的下拉選單，選中旺旺寵物用品行，列表立刻只留下這家店的訂單，剛才建立的這一筆也在裡面，篩選機制在真實新增的資料上，依然如預期運作。

這一整段操作沒有任何一步是今天新學的技術，選客戶用的是 Day 9 的機制，管理明細用的是 Day 11 的機制，看客戶名稱跟篩選用的是 Day 10 的機制。今天要證明的事情，不是重新教一次這三個機制各自怎麼運作，而是這幾個各自成立的機制，串在一起走一次真實流程時，確實是通的。從選客戶到管理明細再到回頭確認列表，中間沒有卡住、沒有露出裸主鍵、沒有哪個環節需要額外補一段程式碼才能接上，這正是本篇標題「第一次像個真正的系統」要驗證的事。

圖：同一張訂單從建立到確認的完整路徑，依序對應訂單建立表單選擇客戶、Relation Manager 新增兩筆明細、列表頁顯示客戶名稱、套用客戶篩選這四個畫面。

這一步暫時還沒打通，庫存跟訂單明細的關係

流程走完看起來很完整，但這裡要誠實點出一個目前完全沒處理的環節。剛才那筆訂單明細，飼料訂了十件，商品 Resource 裡那筆飼料的庫存數量欄位，不會因此自動減少十。兩者之間，目前沒有任何自動連動的機制，訂單明細裡填的數量跟商品自身的庫存數量，是兩個完全獨立的數字，各自躺在各自的資料表裡，誰變動都不會影響另一邊。

這個落差不是這個階段的任務範圍，而是業務語意上真實存在、但技術上還沒觸及的下一層問題。

回頭看 Day 01：為什麼是 Filament，跟手刻後台與其他套件比起來差在哪 定案的業務語意，訂單會影響庫存水位，這句話從系列第一天就寫在那裡，但到今天為止，這句話還只是文字描述，尚未在示範專案裡真正實現。

賣出去的商品理應反映在庫存數量上，這是任何一套真實運作的批發商後台都繞不開的業務邏輯，示範專案目前完全沒有碰到這一層。

這裡順帶說明為什麼今天不處理這個問題。這件事牽涉的是資料儲存前後該自動觸發什麼邏輯，一筆訂單明細存檔的那一刻，理應同時去扣減對應商品的庫存數量，這種性質的機制跟今天處理的「關聯資料怎麼呈現與管理」是不同層次的問題。今天處理的三件事，表單選關聯、表格顯示關聯、巢狀資料管理，核心都是資料怎麼被看見跟操作，庫存連動要處理的是資料變動時該自動觸發什麼，性質完全不一樣，留給後續階段處理更合適，這裡不展開任何具體實作方向。老實承認這個落差，比假裝系統已經完美無缺更有意義，畢竟讀者遲早會自己動手試，一試就會發現庫存數字動也不動。

資料關聯這四天，後台長出了骨架之間的血肉

今天是第三階段「資料關聯」的收尾篇，適合停下來完整回顧這四天走過的路徑。

Day 9 讓客戶、訂單兩個模組從無到有登場，客戶先於訂單存在，因為訂單如果沒有客戶可選就沒有意義。這一天也拆解了表單裡關聯欄位選擇資料背後查詢跟儲存的機制，選項來自即時查詢另一張資料表，顯示的是有意義的文字，存進資料庫的卻是主鍵，這跟固定選項下拉選單是完全不同的兩套邏輯。

Day 10 讓表格也能顯示關聯資料，訂單列表第一次看得出屬於哪個客戶，裸主鍵數字第一次變成一眼可讀的店名，還補上依客戶篩選訂單這個延伸情境。表單端跟表格端在這一天正式對齊，Day 9 留下的落差在這一天被實際補齊。

Day 11 引入訂單明細，解決一張訂單只能對應一個商品的限制，也定案了 Relation Manager 這個系列既定錨點。一張訂單底下能自由記錄多個品項，新增、編輯、刪除都在同一個畫面完成，不需要離開訂單頁面去別的地方操作。

今天則把這幾天各自建立的機制串成一次完整的業務流程，從選客戶、管理明細，到回頭在列表上確認結果，中間沒有斷點。

把這階段前後對照一下，落差相當具體。

這個階段開始之前，示範專案只有商品這一個孤立的 Resource，訂單、客戶都還只是業務語意裡的文字描述，連 Model 都不存在。階段結束的今天，商品、客戶、訂單、訂單明細四者透過關聯緊密相連，一次下單操作會同時牽動這四個模組，選客戶動到訂單跟客戶兩張表，新增明細動到訂單明細跟商品兩張表。這是全系列第一次，讀者能感受到眼前這套後台開始像是在管理一個真實運作中的業務，不再是四個各自展示技巧的獨立範例。剛才提到的那四個抽屜，今天總算被畫上了一條看得見的線。

這條線也呼應系列一直在講的那條主線，陽春後台逐步加深。前兩個階段做的事情，是把單一個 Resource 從能動做到好用，表單欄位選對型別、表格欄位排版清楚、篩選排序一應俱全，這些進展發生在單一個模組內部，像是把一副骨架的每一根骨頭都磨得更精細。這個階段做的事情性質不同，是把多個 Resource 之間原本斷開的關係接起來，讓骨架跟骨架之間長出血肉，單獨看每一根骨頭可能都沒有變化，但整個骨架第一次能夠聯動，一個部位牽動另一個部位。兩種進展性質不同，但同樣重要，少了任何一種，都不會是一套真正能用的系統。

下一步是讓這套系統更嚴謹

今天走完的整合流程證明了關聯是通的，但通了不代表嚴謹。

剛才示範建立訂單明細的時候，數量欄位目前只做了最基本的必填限制，使用者如果手滑填入負數，或是打進一個不合常理的超大數字，介面完全不會阻擋，這筆明細照樣能存進資料庫。關聯打通只解決了「資料能不能被正確串起來」的問題，還沒有處理「填進去的值本身合不合理」這個更細緻的層次。

表單驗證不只是必填，跨欄位規則怎麼寫，是接下來要處理的內容。第三階段「資料關聯」到今天正式收尾，商品、客戶、訂單、訂單明細第一次串成一條完整的業務流程，這套後台第一次感覺像是在管理一個真實運作中的業務，而不只是四個各自獨立展示技巧的範例。