資料庫表字段命名規範

資料庫表字段命名規範

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

本文是一篇包含了資料庫命名、資料庫表命名、資料庫表字段命名及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