兜兜轉轉， 突然發現我現在已經是一個老司機了， 一直寫代碼都很忙， 沒有把很多點點滴滴的記錄下來， 今天開始就開始一個系列， 分析當年我接觸或者我設計過的表結構， 有好有壞， 有歡喜也有淚水。 很多實踐經驗來自於踩了一個又一個的坑， 從現在的角度去回想， 在設計的時候如果那麼做， 也許我就不需要改代碼了……
歡迎各位在評論區討論， 我只是想分享一下看法， 也許有高人有更好的解法。 以下案例從我的實踐中簡化而來， 個別命名或者設計請勿對號入座， 欄位名等也是隨便寫的， 只作示例。
問題：一個流程管理的模組如何設計表結構
需求細節：產品的需求大約是這樣， 一個訂單取消退貨的流程， 中間有審批環節， 所有人都通過以後， 可以執行取消動作， 所有的退訂申請都需要有時間記錄。
Round1
開發疑問：
（此處內心暗暗的罵產品經理一千遍， 又來搞我， 一句話需求。 ）
數據量多大？不知道
審核動作需要記錄什麼？審核人， 審核時間。
審核人有幾個？3個， 銷售主管， 銷售總監， 財務
Round2
產品看了一下， 似乎和他說的差不多， 沒毛病。 轉過一圈後問， 我們可以獲取到每個取消訂單的耗時嗎？媽蛋， 二次需求或者說沒把需求一次說全。 這個時候開發就需要自行幫產品經理腦補。 那麼
申請退款的發起人不一定是客戶， 是不是也需要記錄？
即使審核完成， 最後執行退貨動作也需要耗時間， 那麼退貨開始和結束時間其實需要另外的兩個欄位來記錄？
OK， 那麼把各種時間都給它加上。 這個時候設計上沒什麼難度， 難度是誰知道產品經理給你漏了什麼關鍵需求……
Round3
產品經理退下之後， 給銷售經理打了個電話， 聽說你們有一個退貨的需求？
是， 是， 最近不是315嘛， 客戶要退， 那麼就必須給退啊， 客戶是上帝啊。 哦對了， 我們這裡退貨還要分全退和部分退， 這個可以支援嗎？
什麼鬼？那如果部分退， 我是不是還要收手續費？
沒錯啊， 財務是這麼定的，
媽蛋， 我讓產品經理和你來細化一下需求。
（此處和產品經理撕逼100遍……）
細緻的分析：
退貨有類別的區分， 退貨其實需要按照操作流程， 退貨內容， 審核流程等將表細分， 通過一個統一的退貨id來關聯。
操作流程等的記錄建議分離開來， 否則以後擴展需求會有隱患。
相關的表設計修改如下圖：
cancellation_info:退貨信息， 算是主表
cancellation_audit:退貨審批
cancellation_product:退貨產品及明細
(備註：
退貨產品及相關資訊這裡用到了主從表， 為什麼這麼用或者也許有其他設計， 這裡不作展開， 因為我實際案例中碰到的就是這樣。 也見過把退貨產品加一個類別區分後直接放入訂單表的設計， 這樣以後統計算某產品銷售總數確實是方便了，
Round4
OK， 終於基本搞定銷售經理的需求了， 那麼再給財務打了個電話確認需求。
喂， 聽說我們這裡有一個退貨的需求和您確認一下。
好啊， 現在退貨審批簡化了， 我這裡不需要審批， 只需要執行， 銷售那邊確認完， 算好退款金額給我， 我只執行退款。
什麼？……
（心中默默的哭泣）
疑問點：
流程需要變更嗎？變更頻率是多少？
審核流程是單向的流程嗎？例如取消原因沒寫清楚，是執行退回操作，之後同一筆退訂申請可以再走審核流程，還是必須另起一個流程？
分析：
流程變化這種事很難控制，所以流程和時間節點記錄不能用橫表來擴展，這樣的後果就是一旦流程變更，就要變更資料表。
橫向的表也不能處理跳回和反復執行的流程。
現今的系統設計時，操作人操作時間等的記錄都需要更完善，所以能考慮的都給它考慮上，加上各種note，memo，記錄各種異常情況或者備註以防萬一。
新的audit表不再是按cancellationid對應一條記錄，而是一個cancellationid對應多條記錄，並有了獨立的auditid。而且每一步審核人都可以獨立的記錄result和memo，記錄會更詳盡，各個審核時間也有了一個統一的欄位，之後統計某一個退貨審核的耗時，可以用cancellationid來檢索，最大最小時間相減即可。另外，我個人的建議是將退貨的發起時間和執行完成時間也記錄在此。
Others
實際案例中，還有很多很多的細節，如財務需要記錄憑證和其他事物。銷售那裡還有退貨位址等等
銷售那裡9成會提說有一個當前的退貨狀態的即時報表，所以在cancellation_info里加個狀態標誌位元等，方便實際應用我覺得也是可以考慮的設計。
總結
我覺得資料表設計2個主要思辨方向：一個是業務驅動，一個是統計驅動。
業務驅動是說，業務需求需要你把各種資料記錄下來，沒有記錄以後就做不了相關的功能，然後我們按照各種資料庫設計的模式記錄資料。統計驅動是說滿足了基本業務流程需要後，很多資料的實際應用主要是各種統計報表中，要考慮到統計報表時獲取資料的方便性。在設計時，兼顧考慮2方面的需求，這個案例主要說的是業務相關的驅動，要統計審核時間等又與統計驅動有關。
設計多個表其實對於開發來說沒有什麼難度，難度在於業務經驗，預知可能的變化點，提前做好規劃。一個好的產品經理如果能及早的想到這些點，那麼開發就可以少走很多的彎路。如果產品經理幫不了忙，那麼只有靠自己，多和各個實際業務打打交道。
流程記錄，步驟記錄，時間點記錄，建議用不要用橫向設計。
我只執行退款。什麼？……
（心中默默的哭泣）
疑問點：
流程需要變更嗎？變更頻率是多少？
審核流程是單向的流程嗎？例如取消原因沒寫清楚，是執行退回操作，之後同一筆退訂申請可以再走審核流程，還是必須另起一個流程？
分析：
流程變化這種事很難控制，所以流程和時間節點記錄不能用橫表來擴展，這樣的後果就是一旦流程變更，就要變更資料表。
橫向的表也不能處理跳回和反復執行的流程。
現今的系統設計時，操作人操作時間等的記錄都需要更完善，所以能考慮的都給它考慮上，加上各種note，memo，記錄各種異常情況或者備註以防萬一。
新的audit表不再是按cancellationid對應一條記錄，而是一個cancellationid對應多條記錄，並有了獨立的auditid。而且每一步審核人都可以獨立的記錄result和memo，記錄會更詳盡，各個審核時間也有了一個統一的欄位，之後統計某一個退貨審核的耗時，可以用cancellationid來檢索，最大最小時間相減即可。另外，我個人的建議是將退貨的發起時間和執行完成時間也記錄在此。
Others
實際案例中，還有很多很多的細節，如財務需要記錄憑證和其他事物。銷售那裡還有退貨位址等等
銷售那裡9成會提說有一個當前的退貨狀態的即時報表，所以在cancellation_info里加個狀態標誌位元等，方便實際應用我覺得也是可以考慮的設計。
總結
我覺得資料表設計2個主要思辨方向：一個是業務驅動，一個是統計驅動。
業務驅動是說，業務需求需要你把各種資料記錄下來，沒有記錄以後就做不了相關的功能，然後我們按照各種資料庫設計的模式記錄資料。統計驅動是說滿足了基本業務流程需要後，很多資料的實際應用主要是各種統計報表中，要考慮到統計報表時獲取資料的方便性。在設計時，兼顧考慮2方面的需求，這個案例主要說的是業務相關的驅動，要統計審核時間等又與統計驅動有關。
設計多個表其實對於開發來說沒有什麼難度，難度在於業務經驗，預知可能的變化點，提前做好規劃。一個好的產品經理如果能及早的想到這些點，那麼開發就可以少走很多的彎路。如果產品經理幫不了忙，那麼只有靠自己，多和各個實際業務打打交道。
流程記錄，步驟記錄，時間點記錄，建議用不要用橫向設計。