數據結構設計經驗總結

前言

最近一年在公司作了大量的數據結構設計工做，目前對於設計工做也算駕輕就熟了。

在這裏把本身在數據結構設計中的心得總結一下，方便本身查看，也方便與你們分享討論。

 

 

正文

一、數據表必備元素

    目前我設計的數據表都會有四個必備元素id，建立時間，修改時間，刪除標誌。

    

 

二、數據的刪除採用「假刪除」方式

    項目中的刪除功能只是改變刪除標誌（state），而不是直接delete掉。好處就是能夠找到全部已經被刪除的歷史數據，也不怕用戶誤操做了，修改一下標誌即可直接找回。

 

三、表關聯「軟硬適度」

    「軟硬適度」這個詞純屬本身發明，「硬關聯」指的是存在外鍵關係的表關聯，而「軟關聯」指的是保存對方id並無實質性的外建關係。這兩種表的關聯方式的運用智者見智，根據實際狀況靈活運用，主要目的在於減小龐大表關係中的耦合度。個人習慣通常是同一業務模塊的使用「硬關聯」，而不一樣業務模塊的使用「軟關聯」。舉個例子，用戶模型中帳號表、權限表之間是「硬關聯」，而帳號表和訂單模型中的訂單表使用「軟關聯」。

 

四、同一業務模塊中的表命名使用相同的開頭

   通常使用數據庫client終端查看錶時，都會採用按照字母順序進行排序，表名開頭相同的表都會聚在一塊兒，在查找問題時很容易就能找到同一業務模塊的一組表。例如店鋪相關表以company開頭，company_datum,company_person,company_level。而不要寫成，datum_company,person_company,level_company。

 

五、表設計不能脫離代碼實現

    設計表的時候必須思考代碼實現，脫離實現的設計會給程序員帶來困擾。個人作法通常都是先按照需求設計關係和字段。而後按照需求去思考每個功能應該怎樣去寫SQL。這樣作的好處是在考慮了開發過程後，能比較清晰地知道數據表設計的是否合理，是否有必要增長一些冗餘和輔助字段去簡化開發工做。

 

六、註釋是很重要滴（老生常談）

    這實在是一個老生常談的問題，學習任何開發語言老師都會不厭其煩的強調，公司領導也是磨破了嘴。可有些人依然我行我素不覺得然。固然也不是全部的狀況都必須詳細的寫註釋，詳細程度也是和項目規模和複雜度決定的。一我的作一個簡單的增刪改查顯然不必太較真。若是是一個公司不停迭代的產品那必要性就比較強了，主要有兩點好處。 第一，若是項目要求不是太嚴格，註釋寫得好程序員能夠直接看着需求原型和數據結構進行開發了。我有過四我的的項目組實踐絕對沒問題的。第二，當項目數據表達到百張以上，開發時間跨度大於一年，以前設計的東西回想起來就比較模糊了，有些時候要花很長時間去回憶當初的設計意圖。

 

七、日誌和記錄表不要光記個id

    日誌和記錄表要直接記錄結果數據而不要僅依賴於相關數據的id。日誌和記錄表是當時發生事件的留存，應該使用相似於快照的概念進行保存。若是僅使用id字段關聯數據，當依賴數據被修改時將沒法查看當時的狀態。訂單表中保存的商品數據是最典型的例子。

 

八、多對多中間表不要使用雙主鍵

    有些朋友在建立多對多關聯表的時候將，關聯的兩個字段設置爲主鍵。這麼設計的優缺點網上也有一些爭議，可是大部分仍是建議不要這麼作。我通常使用與業務無關的id做爲主鍵。

 

九、要關心客戶端開發習慣

     按理說數據結構設計中字段值的設定並不須要關心頁面的展現順序，至少在web開發是這樣的。可是在客戶端開發中若是值的順序和展現順序一致會給客戶端開發人員帶來一些便利。下面我舉一個真實例子。

需求：客戶端要展現一個多頁籤頁面，可使用手勢進行橫向滑動。四個頁籤按順序爲 待接待、已接待、已完成、已取消。

客戶端：使用了一款橫向滑動組件進行開發

數據庫：接待狀態這個字段設計成int類型，而且值的順序按照需求順序排列  1-待接待、2-已接待、3-已完成、4-已取消。

    這個例子中若是數據庫的值順序與需求不一致，客戶端就須要增長額外的判斷來控制滑動組件。

 

其實還有不少須要注意的地方，一時想不起來，這篇博客我會一直補充修正的。