摘要：當前研發(fā)工作中經(jīng)常出現(xiàn)因數(shù)據(jù)庫表、數(shù)據(jù)庫表字段格式不規(guī)則而影響開發(fā)進度的問題，在后續(xù)開發(fā)使用原來數(shù)據(jù)庫表時，也會因為數(shù)據(jù)庫表的可讀性不夠高，表字段規(guī)則不統(tǒng)一，造成數(shù)據(jù)查詢，數(shù)據(jù)使用效率低的問題，所以有必要整理出一套合適的數(shù)據(jù)庫表字段命名規(guī)范來解決優(yōu)化這些問題。

本文是一篇包含了數(shù)據(jù)庫命名、數(shù)據(jù)庫表命名、數(shù)據(jù)庫表字段命名及SQL語言編碼的規(guī)范文檔，針對研發(fā)中易產(chǎn)生的問題和常見錯誤做了一個整理和修改，為日后涉及到數(shù)據(jù)庫相關(guān)的研發(fā)工作做好準備。

一、數(shù)據(jù)庫命名規(guī)范

采用26個英文字母(區(qū)分大小寫)和0-9的自然數(shù)(經(jīng)常不需要)加上下劃線'_'組成，命名簡潔明確，多個單詞用下劃線'_'分隔，一個項目一個數(shù)據(jù)庫，多個項目慎用同一個數(shù)據(jù)庫

二、數(shù)據(jù)庫表命名規(guī)范

2.1數(shù)據(jù)表命名規(guī)范

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

(2)全部小寫命名，禁止出現(xiàn)大寫

(3)禁止使用數(shù)據(jù)庫關(guān)鍵字，如：name，time ，datetime，password等

(4)表名稱不應(yīng)該取得太長(一般不超過三個英文單詞)

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

(6)用單數(shù)形式表示名稱，例如，使用 employee，而不是 employees

明細表的名稱為：主表的名稱+字符dtl(detail縮寫)

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

(7)表必須填寫描述信息(使用SQL語句建表時)

2.2命名規(guī)范

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

② 功能點? 示例：live?? message

③ 通用表? 示例：all_user

2.3待優(yōu)化命名示例

①冗余：

錯誤示例：yy_alllive_video_recomment??? yy_alllive_open_close_log

說明：去除項目名，簡化表名長度，去”yy_”

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

錯誤示例：yy_all_live_category??? yy_alllive_comment_user

說明：去除項目名，統(tǒng)一命名規(guī)則，均為”yy_alllive_”開頭即可

③命名格式存在差異

錯誤示例：yy_showfriend??? yy_user_getpoints??? yy_live_program_get

說明：去除項目名，統(tǒng)一命名規(guī)則，動賓短語分離且動賓邏輯順序統(tǒng)一

三、數(shù)據(jù)庫字段命名規(guī)范

3.1字段命名規(guī)范

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

(2)全部小寫命名，禁止出現(xiàn)大寫

(3)字段必須填寫描述信息

(4)禁止使用數(shù)據(jù)庫關(guān)鍵字，如：name，time ，datetime password?等

(5)字段名稱一般采用名詞或動賓短語

(6)采用字段的名稱必須是易于理解，一般不超過三個英文單詞

(7)在命名表的列時，不要重復表的名稱

例如，在名employe的表中避免使用名為employee_lastname的字段

(8)不要在列的名稱中包含數(shù)據(jù)類型

(9)字段命名使用完整名稱，禁止縮寫

3.2命名規(guī)范

①名詞? 示例：user_id??? user_name??? sex

②動賓短語? 示例：is_friend?? is_good

3.3待優(yōu)化命名示例

①大小寫規(guī)則不統(tǒng)一

錯誤示例：user_id??? houseID

說明：使用統(tǒng)一規(guī)則，修改為”user_id”，”house_id”

②加下劃線規(guī)則不統(tǒng)一

錯誤示例：username??? userid??? isfriend??? isgood

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

③字段表示不明確

錯誤示例：uid??? pid

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

3.4字段類型規(guī)范

(1)所有字段在設(shè)計時，除以下數(shù)據(jù)類型timestamp、image、datetime、smalldatetime、uniqueidentifier、binary、sql_variant、binary 、varbinary外，必須有默認值，字符型的默認值為一個空字符值串’’，數(shù)值型的默認值為數(shù)值0，邏輯型的默認值為數(shù)值0

(2)系統(tǒng)中所有邏輯型中數(shù)值0表示為“假”，數(shù)值1表示為“真”，datetime、smalldatetime類型的字段沒有默認值，必須為NULL

(3)用盡量少的存儲空間來存儲一個字段的數(shù)據(jù)

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

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

IP地址使用int類型

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

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

最好給每個字段一個默認值，最好不能為null

(4)用合適的字段類型節(jié)約空間

字符轉(zhuǎn)化為數(shù)字(能轉(zhuǎn)化的最好轉(zhuǎn)化，同樣節(jié)約空間、提高查詢性能)

避免使用NULL字段(NULL字段很難查詢優(yōu)化、NULL字段的索引需要額外空間、NULL字段的復合索引無效)

少用text類型(盡量使用varchar代替text字段)

3.5數(shù)據(jù)庫中每個字段的規(guī)范描述

(1)盡量遵守第三范式的標準(3NF)

表內(nèi)的每一個值只能被表達一次

表內(nèi)的每一行都應(yīng)當被唯一的標示

表內(nèi)不應(yīng)該存儲依賴于其他鍵的非鍵信息

(2)如果字段事實上是與其它表的關(guān)鍵字相關(guān)聯(lián)而未設(shè)計為外鍵引用，需建索引

(3)如果字段與其它表的字段相關(guān)聯(lián)，需建索引

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

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

四、SQL語言編碼規(guī)范

4.1大小寫規(guī)范

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

(2)所有函數(shù)及其參數(shù)中除用戶變量以外的部分必須大寫

(3)在定義變量時用到的數(shù)據(jù)類型必須小寫

4.2注釋

注釋可以包含在批處理中，在觸發(fā)器、存儲過程中包含描述性注釋將大大增加文本的可讀性和可維護性，本規(guī)范建議：

(1)注釋以英文為主，實際應(yīng)用中，發(fā)現(xiàn)以中文注釋的SQL語句版本在英文環(huán)境中不可用，為避免后續(xù)版本執(zhí)行過程中發(fā)生某些異常錯誤，建議使用英文注釋

(2)注釋盡可能詳細、全面創(chuàng)建每一數(shù)據(jù)對象前，應(yīng)具體描述該對象的功能和用途，傳入?yún)?shù)的含義應(yīng)該有所說明，如果取值范圍確定，也應(yīng)該一并說明，取值有特定含義的變量(如boolean類型變量)，應(yīng)給出每個值的含義

(3)注釋語法：單行注釋、多行注釋

單行注釋：注釋前有兩個連字符(--)對變量、條件子句可以采用該類注釋

多行注釋：符號之間的內(nèi)容為注釋內(nèi)容，對某項完整的操作建議使用該類注釋

(4)注釋簡潔，同時應(yīng)描述清晰

(5)函數(shù)注釋：

編寫函數(shù)文本--如觸發(fā)器、存儲過程以及其他數(shù)據(jù)對象--時，必須為每個函數(shù)增加適當注釋，該注釋以多行注釋為主，主要結(jié)構(gòu)如下：

CREATE?PROCEDURE?sp_xxx

總結(jié)

以上是生活随笔為你收集整理的sql语句中表格缩写命名_数据库表字段命名规范的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。