資料庫表欄位命名規範

摘要：當前研發工作中經常出現因資料庫表、資料庫表欄位格式不規則而影響開發進度的問題，在後續開發使用原來資料庫表時，也會因為資料庫表的可讀性不夠高，表欄位規則不統一，造成資料查詢，資料使用效率低的問題，所以有必要整理出一套合適的資料庫表欄位命名規範來解決最佳化這些問題。

本文是一篇包含了資料庫命名、資料庫表命名、資料庫表欄位命名及SQL語言編碼的規範文件，針對研發中易產生的問題和常見錯誤做了一個整理和修改，為日後涉及到資料庫相關的研發工作做好準備。

一、資料庫命名規範

採用26個英文字母(區分大小寫)和0-9的自然數(經常不需要)加上下劃線'_'組成，命名簡潔明確，多個單詞用下劃線'_'分隔，一個專案一個資料庫，多個專案慎用同一個資料庫

二、資料庫表命名規範

2.1資料表命名規範

（1）採用26個英文字母(區分大小寫)和0-9的自然數(經常不需要)加上下劃線'_'組成，命名簡潔明確，多個單詞用下劃線'_'分隔

（2）全部小寫命名，禁止出現大寫

（3）禁止使用資料庫關鍵字，如：name，time ，datetime，password等

（4）表名稱不應該取得太長（一般不超過三個英文單詞）

（5）表的名稱一般使用名詞或者動賓短語

（6）用單數形式表示名稱，例如，使用 employee，而不是 employees

明細表的名稱為：主表的名稱+字元dtl（detail縮寫）

例如：採購定單的名稱為：po_order，則採購定單的明細表為：po_orderdtl 

（7）表必須填寫描述資訊（使用SQL語句建表時）

2.2命名規範

①模組_+功能點  示例：alllive_log   alllive_category

②功能點  示例：live   message

③通用表  示例：all_user

2.3待最佳化命名示例

①冗餘：

錯誤示例：yy_alllive_video_recomment    yy_alllive_open_close_log

說明：去除專案名，簡化表名長度，去”yy_”

②相同類別表命名存在差異，管理性差

錯誤示例：yy_all_live_category    yy_alllive_comment_user

說明：去除專案名，統一命名規則，均為”yy_alllive_”開頭即可

③命名格式存在差異

錯誤示例：yy_showfriend    yy_user_getpoints    yy_live_program_get

說明：去除專案名，統一命名規則，動賓短語分離且動賓邏輯順序統一

三、資料庫欄位命名規範

3.1欄位命名規範

（1）採用26個英文字母(區分大小寫)和0-9的自然數(經常不需要)加上下劃線'_'組成，命名簡潔明確，多個單詞用下劃線'_'分隔

（2）全部小寫命名，禁止出現大寫

（3）欄位必須填寫描述資訊

（4）禁止使用資料庫關鍵字，如：name，time ，datetime password 等

（5）欄位名稱一般採用名詞或動賓短語

（6）採用欄位的名稱必須是易於理解，一般不超過三個英文單詞

（7）在命名錶的列時，不要重複表的名稱

例如，在名employe的表中避免使用名為employee_lastname的欄位

（8）不要在列的名稱中包含資料型別

（9）欄位命名使用完整名稱，禁止縮寫

3.2命名規範

①名詞  示例：user_id    user_name    sex

②動賓短語  示例：is_friend   is_good

3.3待最佳化命名示例

①大小寫規則不統一

錯誤示例：user_id    houseID

說明：使用統一規則，修改為”user_id”，”house_id”

②加下劃線規則不統一

錯誤示例：username    userid    isfriend    isgood

說明：使用下劃線進行分類，提升可性，方便管理，修改為”user_name”，”user_id”，”is_friend”，”is_good”

③欄位表示不明確

錯誤示例：uid    pid

說明：使用完整名稱，提高可讀性，修改為”user_id”，”person_id”

3.4欄位型別規範

（1）所有欄位在設計時，除以下資料型別timestamp、image、datetime、smalldatetime、uniqueidentifier、binary、sql_variant、binary 、varbinary外，必須有預設值，字元型的預設值為一個空字元值串’’，數值型的預設值為數值0，邏輯型的預設值為數值0

（2）系統中所有邏輯型中數值0表示為“假”，數值1表示為“真”，datetime、smalldatetime型別的欄位沒有預設值，必須為NULL

（3）用盡量少的儲存空間來儲存一個欄位的資料

使用int就不要使用varchar、char，

用varchar(16)就不要使varchar(256)

IP地址使用int型別

固定長度的型別最好使用char，例如：郵編(postcode)

能使用tinyint就不要使用smallint，int

最好給每個欄位一個預設值，最好不能為null

（4）用合適的欄位型別節約空間

字元轉化為數字(能轉化的最好轉化，同樣節約空間、提高查詢效能)

避免使用NULL欄位(NULL欄位很難查詢最佳化、NULL欄位的索引需要額外空間、NULL欄位的複合索引無效)

少用text型別(儘量使用varchar代替text欄位)

3.5資料庫中每個欄位的規範描述 

   （1）儘量遵守第三正規化的標準（3NF） 

     表內的每一個值只能被表達一次 

     表內的每一行都應當被唯一的標示 

     表內不應該儲存依賴於其他鍵的非鍵資訊

(2)如果欄位事實上是與其它表的關鍵字相關聯而未設計為外來鍵引用，需建索引

(3)如果欄位與其它表的欄位相關聯，需建索引

(4)如果欄位需做模糊查詢之外的條件查詢，需建索引

(5)除了主關鍵字允許建立簇索引外，其它欄位所建索引必須為非簇索引

四、SQL語言編碼規範 

4.1大小寫規範 

（1）所有關鍵字必須大寫，如：INSERT、UPDATE、DELETE、SELECT及其子句，IF……ELSE、CASE、DECLARE等

（2）所有函式及其引數中除使用者變數以外的部分必須大寫

（3）在定義變數時用到的資料型別必須小寫

4.2註釋 

註釋可以包含在批處理中，在觸發器、儲存過程中包含描述性註釋將大大增加文字的可讀性和可維護性，本規範建議： 

（1）註釋以英文為主，實際應用中，發現以中文註釋的SQL語句版本在英文環境中不可用，為避免後續版本執行過程中發生某些異常錯誤，建議使用英文註釋

（2）註釋儘可能詳細、全面建立每一資料物件前，應具體描述該物件的功能和用途，傳入引數的含義應該有所說明，如果取值範圍確定，也應該一併說明，取值有特定含義的變數（如boolean型別變數），應給出每個值的含義

（3）註釋語法：單行註釋、多行註釋 

單行註釋：註釋前有兩個連字元（--）對變數、條件子句可以採用該類註釋

多行註釋：符號之間的內容為註釋內容，對某項完整的操作建議使用該類註釋

（4）註釋簡潔，同時應描述清晰

（5）函式註釋： 

編寫函式文字--如觸發器、儲存過程以及其他資料物件--時，必須為每個函式增加適當註釋，該註釋以多行註釋為主，主要結構如下： 

CREATE PROCEDURE sp_xxx 

 作者：

原文連結：https://www.cnblogs.com/zhuhui-site/p/10043665.html