2026 年 9 月 17 日，掘金上有一篇技術長文被反覆轉載：一份 KDMS 資料庫遷移評估報告，到底該怎麼排出遷移的先後順序。文章裡講的是物件相容度、POC 驗證、批次快照，全是工程術語。但如果你曾經在家裡辦過一桌菜，你會立刻看懂它在說什麼。
辦桌的第一刻，人總是樂觀的。菜單開好了，材料清單列出來了，算一算十二道菜，感覺兩三個小時能搞定。這就像遷移報告的首頁：物件都採集完了，總相容度也有了，一片綠燈。可是真的人站到爐子前，問題馬上變了。一道涼拌小黃瓜，拍一拍、撒點鹽、淋點麻油，五分鐘上桌。一道佛跳牆，得先吊高湯、炸芋頭、處理豬腳筋，前一晚就要動工。這兩道菜在菜單上都叫「一道」，工作量卻是天差地遠。原文裡那句話說得極準：一張只有幾列的普通表，和一個包含動態 SQL、例外分支、遊標與多表依賴的預存程序，不能按「一個物件」算成同樣的工作量。總相容度能回答方向，排期還得回到物件明細。
菜單能告訴你有幾道菜，辦不了桌。真正辦桌的人，看的是每一道菜的火候。
先把這一輪盤點固定下來
那篇長文裡有個作法，我讀到時忍不住點頭。它說，不要讓第二次評估直接蓋掉第一次，要留一份物件快照，把每一批的評估結論、問題數、預估工作量都存下來，連同物件定義的摘要一起。為什麼？因為源資料庫會繼續被改動。你必須分得清楚，哪些問題是本來就在的，哪些是評估之後才被改出來的。
這像極了冰箱上那張採買清單。禮拜天早上你去市場，把當週要用的菜列下來：絲瓜兩條、排骨一斤、蛋一盒。但你太太下午又去了一趟超市，買了蝦回來。如果清單不改，到了禮拜四你會站在冰箱前疑惑：這蝦是哪來的？什麼時候買的？還新鮮嗎？廚房裡最怕的從來沒有菜，怕的是帳對不上。留快照，就是把每一趟採買的單據都收好，將來對帳的時候才有依據。
廚房的老規矩其實是一樣的：高湯每天打掉多少、補多少、什麼時候補的，老師傅都記在心裡，或寫在牆上的白板。那塊白板從來不是裝飾，它是這鍋湯的履歷。
統計完了，菜要分兩堆
文章接著給了一段查詢，把物件類型和評估結論拆開來看。跑完之後你可能會發現：大部分的 TABLE 都是「可處理」狀態，而 ROUTINE、TRIGGER 集中在「需檢視」或「不相容」。這時排期就不能按物件總數平均分配了。
翻譯成辦桌的語言就是：涼拌菜一堆，硬菜一堆。小黃瓜、涼拌豆腐、皮蛋豆腐，這一堆可以流水線處理，洗、切、擺盤，叫家裡的小孩來幫忙都行。但紅燒獅子頭、糖醋魚、需要起油鍋炸再燴的那些，得老闆娘親自站上爐臺，一道一道盯。如果你把十二道菜平均排成十二個時段，最後的畫面一定是：涼拌菜早就做好在旁邊出水，獅子頭還在鍋裡冒油。
先挑會拖住聯調的物件。原文這句話，就是辦桌師傅的直覺：先把最難、被最多人等的那道菜動工。高風險的預存程序、被多個模組引用的視觀表、依賴觸發器的寫入鏈路，通常比一批獨立的小表更值得先驗證。就像辦桌時那鍋高湯，十道菜裡有六道要用它，它不先起來，後面全部乾等。
這道理我們在一個人備百人辦桌的故事裡也聊過：大菜和小菜的額度，從來就不能一視同仁。
POC 不是把所有菜都炒一遍
遷移初期做 POC，很多人第一個直覺是把所有不相容的項目一次做完，證明什麼都能解。原文潑了冷水：更實用的做法，是按風險、問題數和預估工作量把候選物件排出來，再結合實際呼叫鏈確定範圍。
辦桌前試菜也是這樣。你不會把十二道菜全部試做一遍，那是辦兩次桌。你只試最沒把握的那幾道：這批幹貝會不會縮、新買的醬油顏色會不會太深、阿嬤那道菜的火候自己記不記得準。試菜的目的是消除最大的不確定性，其餘有把握的，開桌當天照食譜走就行。這與我們之前聊過的備菜哲學是同一件事：不是一進廚房就把所有菜下鍋，而是想清楚順序。
試完之後，還有一件事最容易被忽略：把試菜的結論寫下來。哪道菜減了糖、哪道換了醋，當天不要靠記憶。遷移也一樣，首輪評估挑了哪些物件做 POC、源庫後來又改了什麼、轉換後的物件有沒有真的落到目標資料庫，這些都要能反覆核對。原文那句話值得抄在牆上：評估報告不替代遷移和回歸，但它應當成為後續工作的基準，而不是開完審會就歸檔的一份 PDF。
一場好的辦桌，從對帳開始
評估、轉換、驗證，本來就是前後銜接的幾項工作。原文說，KDMS 給出的物件和 SQL 評估結果，正好可以用來確定前兩輪最該驗證什麼。這三件事的關係，像備料、開火、上菜：備料決定你能開多大的桌，開火決定味道對不對，上菜那一刻，客人才知道你這幾天在忙什麼。
所以，如果你手上也有一份看起來一片樂觀的評估報告，先別急著鬆口氣。翻到物件明細那一頁，把涼拌菜和佛跳牆分開放，先讓高湯上爐，再給小孩拍小黃瓜的任務。冰箱上貼一張會更新的清單，把每一輪的樣子都留著。
辦桌的從容，從來不靠菜單漂亮，靠的是知道哪道菜先下鍋。