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