如下基本原則適用於全部數據庫對象命名,如無特別說明則爲強制規範。數據結構
Ø規範:遵循行業規範函數
當有相關國家/行業強制性數據結構標準規範存在時,用於存儲某業務數據的業務表在表名命名上原則上應該聽從標準規定,其表中相關字段的中文名稱(即數據項名稱)若標準規範上有規定的應遵循規定。此外,若標準規範上對數據項的類型、長度有規定的,原則上也應當遵循或保證能直接兼容保存和訪問。工具
Ø規範:字母所有大寫原則編碼
全部數據庫對象命名字母所有大寫。Oracle對大小寫不敏感,可是有些數據庫對大小寫敏感,統一大寫有助於在多個數據庫間移植。spa
Ø規範:字符範圍原則設計
只能使用英文字母、下劃線、數字進行命名,首位字符必須是英文字母。日誌
Ø規範:分段命名原則代碼規範
命名中多個單詞間採用下劃線分隔,以便閱讀同時方便某些工具對數據庫對象的映射。如XXX_XXX_XXX,但不限於三段式。
Ø規範:勿用保留詞
數據庫對象命名不能直接使用數據庫保留關鍵字,但分段中可使用。如USER不能用於表名、列名等,可是USER_NAME能夠用於列名,USER_INFO也能夠用於表名。詳細保留關鍵字請參見最後第6.1節,保留字。
Ø規範:簡單命名原則
命名儘量簡單,避免太長的命名,儘可能使用縮寫形式,可是縮寫也要可以表達命名的含義。數據庫對象命名總長度不得超過30字節,以避免超過數據庫命名長度限制(Oracle有30的限制,Mysql爲64,SQL SERVER也是64)。建議每一個單詞分段長度不要超過6位。
Ø建議:富有含義原則
數據庫對象命名一般用能表示其內容或者含義的英文單詞或其縮寫表示也可用其中文名稱各字詞的拼音首寫字母或者拼音簡寫方式表示。數字應儘可能避免使用。
此外在公安行業,對於業務表上表示業務屬性的字段名(即字段英文名)的命名,業內廣泛默認的規範一般是以其中文名稱的每一個漢字拼音首字母組成。考慮行業習慣和一般思路建議用:建議用於表示用戶業務應用屬性的數據項字段名採用中文拼音首字母命名,對於其它純粹用於應用系統內部使用的則儘可能使用英文單詞進行命名。另外,當按中文名稱拼音首字母組合出來後出現與其它字段名重名時,則將最後命名的這個數據項的最後一個漢字用其完整拼音字母代替。
Ø建議:同義性原則
對於同一含義儘可能使用相同的單詞命名,無論使用英文單詞、英文縮寫仍是拼音首字母,以避免引發誤解。如TELEPNHOE的A表中表示固定電話號碼,在B表中就不該該用於表示移動電話號碼。儘可能避免同一單詞表示多種含義的狀況。
Ø建議:命名方式一致原則
在一個系統、一個項目中儘可能採用一致的命名方式,都採用英文單詞或者拼音首字母。尤爲要避免在一個對象命名中同時採用英文單詞和拼音首字母。如確實須要在一個項目中採用兩種命名方式,考慮系統功能設計相關表(開發)使用英文單詞命名,業務相關的表(實施)使用拼音首字母。
Ø建議:擴展性原則
各系統或者項目在遵循本規範的基礎上能夠根據須要制定更明確的規範細則,以知足項目管理須要。如對模塊進行統一命名,而後用於表名的前綴。建議每一個系統在啓動開發時創建數據字典,管理命名中使用的英文單詞、英文單詞縮寫、拼音首字母縮寫等,對用於命名的單詞進行統一管理。
Ø規範:如下對象命名採用固定前綴進行命名,前綴表示數據庫對象的類型,前綴代碼規範以下:
類型 |
前綴規範 |
說明 |
表 |
T_ |
TABLE |
列 |
無 |
無前綴 |
表空間 |
TS_ |
TABLESPACE |
用戶 |
無 |
無前綴 |
分區 |
PT_ |
PARTITION |
視圖 |
VW_ |
VIEW ,V_用於表示變量 |
物化視圖 |
MV_ |
MATERIAL VIEW |
索引 |
IDX_ |
INDEX縮寫,不區分索引類型。約束型索引參照約束命名。 |
主鍵約束 |
PK_ |
PRIMARY KEY |
外鍵約束 |
FK_ |
FOREIGN KEY |
惟一約束 |
UK_ |
UNIQUE KEY |
序列 |
SEQ_ |
SEQUENCE |
函數 |
F_ |
FUNCTION |
過程 |
SP_ |
STORE PROCEDURE |
包 |
PKG_ |
PACKAGE |
觸發器 |
TRG_ |
TRIGGER |
數據庫鏈 |
DBL_ |
DATABASE LINK |
同義詞 |
無 |
通常與目標對象同名須要時以SYN_開頭 |
普通變量 |
V_ |
VARIABLE |
遊標變量 |
CUR_ |
CURSOR |
輸入參數 |
P_ |
PARAMETER |
輸出參數 |
O_ |
OUT |
1.3 表和列Tables and Table Columns
Ø規範:表的命名以T_開頭;
說明:公司一直以來對信息代碼表特殊規範以BM_(表碼)或者DM_(代碼)開頭,考慮歷史特殊狀況信息代碼類表命名方式能夠沿用歷史習慣。表碼錶的規範名稱爲信息代碼表,所以信息代碼表之後將統一使用DM_開頭。
Ø規範:表名採用多段式命名,各單詞間用下劃線分隔;
Ø規範:表名只容許用英文字母、下劃線、數字進行命名,不容許用中文或者其餘符號;
Ø規範:表名所有字母大寫;
Ø規範:根據歷史習慣各系統經常使用表類前綴做以下約定
表分類 |
前綴 |
系統參數類 |
T_SYS_ |
用戶、權限類 |
T_USER_ |
系統日誌類 |
T_LOG_ |
代碼表 |
BM_ |
字典類 |
T_MD |
臨時表 |
T_TMP |
Ø建議:表名也用於相關索引、分區、分區表空間、約束、主鍵等命名,所以爲了不相關對象命名長度超過限制,建議表名長度不要超過20。
Ø建議:表的命名方式建議採用T_MOUDLE_ENTITY方式。MOUDLE表示數據庫對象所屬的系統、模塊名或者主題分類。ENTITY表示目的表表明的實體名稱。MOUDLE 只能由一個單詞組成,ENTITY能夠根據須要有多個單詞組成。
Ø建議:命名時應儘量地使名稱可以清晰準確表達對象的內容,儘量使用能表明其含義的英文單詞、英文單詞縮寫,特殊狀況也可採用拼音首字母。
示例:
1. 系統信息類表以T_SYS_開頭、要素類表以T_IDX_開頭、接口類表以T_INF_開頭、臨時表以T_TMP_開頭、統計分析系統表以T_TJFX_開頭等。表碼類表以BM_開頭並不認爲違反規範,該例做爲規範考慮歷史習慣的特例。 2. T_UserInfo、USER_INFO、UserInfo、T_用戶信息、TB_USER_INFO、TBL_USER_INFO、T$USER$INFO、等都是違反本規範的,正確命名爲T_USER_INFO。 |
Ø規範:列名無需使用前綴,如使用數據類型編碼做爲前綴;
Ø規範:列名只容許用英文字母、下劃線、數字進行命名,不容許用中文或者其餘符號;
Ø規範:列名字母所有大寫;
Ø規範:列名採用多段式命名時,各單詞間用下劃線分隔;
Ø規範:列名不能直接使用數據庫保留字;
Ø建議:列的命名應儘量地採用簡潔明瞭的列名以準確描述列的內容含義, 根據須要能夠一個單詞或者多個單詞進行命名;
Ø建議:日期類型字段推薦以「_DATE」結尾的名字命名,時間類型的字段推薦以「_TIME」結尾的名字命名。
Ø建議:主鍵列命名爲「ID」或者以 「_ID」爲後綴進行命名。對於須要在其餘表中引用的主鍵字段以「_ID」後綴方式命名,普通表主鍵無需加後綴。如基礎信息表的主鍵通常應命名爲「ENTITIE_ID」方式,而一般業務數據明細表的主鍵則直接命名爲「ID」。
示例:
1. 正確命名:USER_NAME、AUDIT_TIME、AUDIT_USER 2. 錯誤命名:USERNAME、UserName、C_USER_NAME、人員姓名,違反規範。 3. 錯誤命名:COMMENT、AUDIT,違反保留字 |
Ø規範:視圖的命名以VW_開頭
Ø規範:視圖其餘命名規範與表名相同
Ø建議:視圖的列名通常與基表一致,可是根據須要能夠與基表的列名不一樣。如接口視圖通常根據接口需求進行命名。
Ø規範:普通索引名稱以IDX_爲前綴,約束性索引命名參見約束章節說明。不區分B-TREE索引,位圖索引、函數索引等類型。
Ø建議:單字段索引的命名方式爲:IDX_表名_字段名,表名無須前綴,命名長度太長時表名和字段名能夠考慮縮寫。
Ø建議:多字段聯合索引命名方式同單字段,考慮長度限制,能夠只列出主要字段名或者採用縮寫方式描述索引字段。
示例:
1. 錯誤命名:IDX_USER_INFO,沒有給出字段名 2. 錯誤命名:B_USER_INFO_DEPT_CODE,前綴錯誤。 |
Ø規範:表空間名以TS_開頭
Ø建議:公用(非分區表專用)表空間命名規範爲:TS_系統名_類型名。類型分爲:數據DATA,索引INDX,也能夠根據須要增長其餘分類。系統名通常與系統主用戶名一致,如門戶系統爲PORTAL。
Ø建議:分區表專用表空間命名規範爲:TS_表名_分區編號。表名能夠不用前綴,分區編號儘可能使用可以表示分區範圍的編號。如按年分區能夠用2004表示2004年的分區。
示例:
1. 正確命名:TS_PORTAL_DATA、TS_PORTAL_INDX分別表示門戶系統的數據表空間和索引表空間。 2. 錯誤命名:PORTAL_DATA(無前綴)、TS_Portal_indx(大小寫) |
Ø建議:分區的命名規範爲爲PT_表名/索引名_Pn。其中,TNAME是指分區表或分區索引的名稱,n是用於區分不一樣分區的惟一識別標誌。若是分區表是以年份的不一樣進行分區,則n爲所表明的年份。
Ø規範:數據庫用戶採用一個表明系統名稱含義的英文單詞或者拼音首字母進行命名,無前綴。
Ø規範:不得使用數據庫自動建立的用戶模式,如SYSTEM、SYS、ROOT等。
Ø建議:建立數據庫用戶時通常不要授予DBA權限。
1.9 完整性約束Integrity Constraints
Ø建議:主鍵約束的命名格式爲PK_表名,表名不帶前綴。如採用字段後加PRIMARY KEY方式添加主鍵則無需命名,由數據庫自動命名。
示例:
1. 表T_SYS_MENU的主鍵約束命名爲PK_SYS_MENU。 |
Ø建議:外鍵約束的命名格式爲FK_表名_字段名,表名不用前綴,字段名較長時能夠縮寫。
建議:惟一關鍵字約束命名規範爲UK_表名,表名能夠不帶前綴。通常狀況不會出現一個表除了主鍵外還有多個惟一約束的狀況,確實須要時能夠命名爲UK_表名_n,n爲索引區分標識能夠是字段名或者序號。
建議:CHECK約束的命名格式爲CK_表名_字段名,表名能夠不帶前綴,名字太長時表名和字段名能夠根據須要縮寫。
建議:同義詞的目的是用於方便對其餘用戶或者數據庫的對象的使用,所以同義詞在命名時,通常與原數據對象名稱相同,如須要前綴可採用SYN_。
Ø規範:序列號的命名應以SEQ_開頭
Ø規範:序列號命名格式爲SEQ_主鍵列名或者SEQ_表名。前者適用於主鍵列用有含義字母進行命名的,後者適用於直接用ID命名主鍵的狀況。表名能夠不用前綴。
示例:
1. 正確命名:SEQ_ORDER_NO用於訂單表頭主鍵列ORDER_NO的序列號,SEQ_ORDER_DETAIL用於訂單明細表主鍵列ID的序列號。 2. 錯誤命名:SQ_ORDER_NO、ORDER_NO、SEQ_order_no |
Ø規範:包的命名以PKG_開頭
Ø建議:包的命名格式PKG_MOUDLE,MOUDLE用表明模塊或者功能組的名字進行命名。建議在有可能的狀況下儘可能使用包。
示例:
1. 正確命名:PKG_REPORT表示報表模塊的包名 2. 錯誤命名:PK_REPORT,PK_前綴用於主鍵。REPORT_PKG,應使用前綴方式命名而不是後綴。Pkg_report,大小寫不符合規範。 |
Ø規範:函數命名以F_開頭
Ø建議:包中的函數的命名規範爲F_NAME,NAME表示相應的功能用途描述;所屬的模塊或者功能組已經在函數所引用的包中指出。
Ø 建議:獨立的函數的命名規範爲F_MODULE_ NAME,MOUDLE可用於指明所屬的模塊的名稱或者功能組。對於基本功能函數,MOUDLE_能夠不須要。
1. 規範:除了前綴改成「SP_」,其他與函數相同。
2.規範:輸入函數命名規範爲P_NAME
3.規範:普通類型變量命名規範爲V_NAME,如數字、字符串、日期等。CURSOR類型變量使用CUR_做爲前綴。隱式遊標變量、記錄類型變量以及對象類型變量按普通變量規範。
4.規範:輸出參數命名規範爲O_NAME,輸出參數放在參數列表最後。
5. 建議:命名規範中的NAME部分應能清楚表示變量或者參數的含義,以提升代碼可讀性。避免使用V_一、V_M、P_一、P_N等沒法表達具體含義的參數或者變量命名。
示例:
1. 正確變量命名: DECLARE 2. 錯誤變量命名: DECLARE 3. 正確參數命名: 4. 錯誤參數命名: |
規範:觸發器的命名規範爲:TRG_表名_觸發器類型。表名不帶前綴,觸發器的類型由觸發時機和觸發動做組成:‘B’表示前觸發,‘A’表示後觸發,‘INSERT’‘UPDATE’‘DELETE’描述觸發動做。
示例:
1.正確命名: 針對業務系統繳費表(前觸發)的觸發器的命名爲TRG_BS_CHARGE_BINSERT。 2.錯誤命名: TRG_BS_CHARGE ,無規定後綴BS_CHARGE_BINSERT,無規定前綴TrgBsCharge,違法大小寫規定和分段命名原則 |