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