資訊專欄INFORMATION COLUMN
摘要：本文主要探討的是如何優雅的設計表結構，讓人能夠直觀的從命名中窺探設計意圖，傳達設計者的設計目的，讓團隊成員達成共識，減少溝通成本。本文將從數據庫表的命名和字段的命名兩個方面展開。
本文首發于知乎專欄，轉載請注明出處 https://zhuanlan.zhihu.com/p/20785905
數據庫表結構設計作為后端軟件開發不可或缺的一環，是每個后端工程師都會經歷的過程。筆者也多次經歷過這樣的過程，也嘗試過多種不同的設計方案，也從一些優秀的框架中學到不少，但并沒有發現相關的文章對其進行總結。所以本文嘗試把筆者看到的、學到的總結下來，希望對閱讀本文的讀者有所啟發。
表結構設計主要有兩個目的，一是讓表結構更加的更具有表現力，做到數據庫表的自描述，減少注釋甚至不使用注釋；二是滿足系統效率和擴展性的需要，讓系統性能更好，后期維護更簡單。
本文主要探討的是如何優雅的設計表結構，讓人能夠直觀的從命名中窺探設計意圖，傳達設計者的設計目的，讓團隊成員達成共識，減少溝通成本。本文不討論表結構設計對性能的影響，也不討論數據庫設計中的范式與反范式設計。本文將從數據庫表的命名和字段的命名兩個方面展開。
數據庫表的命名使用名詞作為表名
仔細想想便可發現，數據庫表中存在的所有數據都是現實世界各種操作的結果，它們有的是中間過程結果，有的是最終數據結果。不論怎樣，它們是一份一份沒有任何動作的，靜態的記錄。而表本身就是存儲這些記錄的容器，從這樣的層面理解，表名應該采用名詞的形式是完全符合邏輯的。
比如我們要設計一個存儲用戶邀請的表，invitation 就比 invite 更加的優雅。
相關表采用統一前綴
我們知道，大型系統的設計往往按模塊或者子系統進行劃分，一個一個模塊的處理問題，保證模塊間的低耦合，模塊內的高內聚。數據庫表設計也一樣，我們可以對相關聯的表采用相同的前綴，使開發人員一眼看上去就知道哪幾個表是相關的。
比如對于用戶基本信息表、用戶的詳細信息表和用戶的微信綁定表如下的命名更可取：
字段的命名user
user_profile
user_wechat
本節先介紹幾個比較通用的原則，使得字段的含義更容易理解，描述性更強，之后進行簡單的總結分類，以便讓我們明白這些原則背后的邏輯。
使用動詞被動形式+描述性后綴
通過前面我們知道，數據庫表中的所有記錄都是靜態的結果性數據，它是由一定的用戶操作產生的。那么它是如何產生的？經過什么樣的操作產生的呢？
在解答之前先看一個例子，下面是一個簡單的 article 表結構：
id: integer
title: varchar
content: text
user_id: integer
create_time: timestamp
這樣的設計本身是沒有問題的，目前用的也很多。這個設計主要的問題是沒有體現出 user_id 與這篇文章的關系，需要經過一定的猜測和思考才能得出。create_time 雖然還比較直觀，但沒有體現出這篇文章實在過去的某個時間創建的。
然后我們在來看修改后的設計：
id: integer
title: varchar
content: text
created_by: integer
created_at: timestamp
通過把 user_id 替換為 created_by、create_time 替換為 created_at，使得我們更容易理解對應的文章是被指定的人在指定的時間創建出來的，而不需要我們的多方猜測或者查閱文檔，使得整個表結構的描述性更強。
時間區分當前時間和未來時間
英語中表時間的時候， at 一般跟一個時間點，而 in 有表示在未來的某個時間之內的意思。結合起來，筆者傾向于用 at 表示過去或者現在的時間，而用 in 表示未來的時間。比如日歷中的 event 有開始時間和結束時間的概念，我覺得如下的命名是比較合理的：
starts_at 事件的開始時間，相對 ends_in 它屬于當前時間，采用 _at 后綴
ends_in 事件的結束時間，相對 ends_in 它屬于未來時間，從用 _in 后綴
其他我們比較常用的比如 created_at、updated_at、expires_in 都屬于這種類型。
使用第三人稱單數
當我們采用動詞+介詞的時候我更傾向與使用第三人稱單數，因為字段描述的這個實體是單數的，通過使用第三人稱單數，我們可以自然語言的方式表達出需要的意思。比如以 event 為例，翻譯成英語是這樣的：
The event starts at 2016-05-05 12:00:00
完全符合英語的語法，也表達了我們想要表達的意思。
區分單數與復數
單數與復數主要是對字段內容的描述，比如通知（notification）有接收人這個字段，如果我們需要通知能夠發送給多個人，那么 receivers 這樣的字段名稱明顯好于 receiver，因為 receivers 體現了通知可以發送給多個人這一個事實。
前面從四個原則出發介紹了如何讓字段更具有描述性，簡單總結下來我覺得從語義上來說，字段可以分為兩種類型：描述性字段和動作性字段。
描述性字段是對對應數據庫記錄（或者說實體）的補充說明，比如以人作為實體，那么人的身高、體重和血壓就屬于這類描述性字段。
描述性字段如果是動詞+介詞的形式，動詞需要采用第三人稱單數的形式，比如 starts_at。然后根據字段的內容，如果內容有多個元素或實體，我們需要使用復數，否則使用單數形式。
動作性字段不僅能對所屬實體進行補充說明，還能對這個實體的所涉及操作有所描述。比如我們有 article 這個實體， article 的 created_by 和 created_at 就屬于動作性字段，因為它不僅表達了 article 的創建者和創建時間這層信息，它還表達了這個 article 是指定的人被創建的，而不是憑空生成的。
2016年5月5日
北京
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/17514.html
摘要：本文主要探討的是如何優雅的設計表結構，讓人能夠直觀的從命名中窺探設計意圖，傳達設計者的設計目的，讓團隊成員達成共識，減少溝通成本。本文將從數據庫表的命名和字段的命名兩個方面展開。 本文首發于知乎專欄，轉載請注明出處 https://zhuanlan.zhihu.com/p/20785905 數據庫表結構設計作為后端軟件開發不可或缺的一環，是每個后端工程師都會經歷的過程。筆者也多次經歷過...
摘要：而漸進增強和優雅降級兩種不同的開發流程，也是在我們項目初期做調研選型時會考慮的一個點。二者區別漸進增強和優雅降級只是看待同種事物的兩種觀點。漸進增強和優雅降級都關注于同一網站在不同設備里不同瀏覽器下的表現程度。 作為一名前端開發人員，最頭疼的莫過于瀏覽器兼容。遠古時期萬惡的IE6，到現在CSS3不兼容的IE7/8.為了保證不同版本瀏覽器都有共同或更優化的用戶體驗，前端搬磚的我們不得不與...
閱讀 2494·2021-11-24 10:29
閱讀 2634·2021-09-24 09:48
閱讀 5737·2021-09-22 15:56
閱讀 3151·2021-09-06 15:00
閱讀 2667·2019-08-30 15:54
閱讀 740·2019-08-30 13:48
閱讀 2892·2019-08-30 11:17
閱讀 3417·2019-08-29 11:20
