http://blog.csdn.net/houseq/article/details/39478687 ### **1.1 基本命名原則** 以下基本原則適用于所有數據庫對象命名，如無特別說明則為強制規范。 **?規范：遵循行業規范** 當有相關國家/行業強制性數據結構標準規范存在時，用于存儲某業務數據的業務表在表名命名上原則上應該遵從標準規定，其表中相關字段的中文名稱（即數據項名稱）若標準規范上有規定的應遵循規定。此外，若標準規范上對數據項的類型、長度有規定的，原則上也應當遵循或保證能直接兼容保存和訪問。 **?規范：字母全部大寫原則** 所有數據庫對象命名字母全部大寫。Oracle對大小寫不敏感，但是有些數據庫對大小寫敏感，統一大寫有助于在多個數據庫間移植。 **?規范：字符范圍原則** 只能使用英文字母、下劃線、數字進行命名，首位字符必須是英文字母。 **?規范：分段命名原則** 命名中多個單詞間采用下劃線分隔，**以便閱讀同時方便某些工具對數據庫對象的映射。如XXX_XXX_XXX，但不限于三段式**。 **?規范：勿用保留詞** 數據庫對象命名不能直接使用數據庫保留關鍵字，但分段中可以使用。如USER不能用于表名、列名等，但是USER_NAME可以用于列名，USER_INFO也可以用于表名。詳細保留關鍵字請參見最后第6.1節，保留字。 **?規范：簡單命名原則** 命名盡可能簡單，避免太長的命名，盡量使用縮寫形式，但是縮寫也要能夠表達命名的含義。數據庫對象命名總長度不得超過30字節，以免超過數據庫命名長度限制（Oracle有30的限制，Mysql為64，SQL SERVER也是64）。建議每個單詞分段長度不要超過6位。 **?建議：富有含義原則** 數據庫對象命名通常用能表示其內容或者含義的英文單詞或其縮寫表示也可用其中文名稱各字詞的拼音首寫字母或者拼音簡寫方式表示。數字應盡量避免使用。 此外在公安行業，對于業務表上表示業務屬性的字段名（即字段英文名）的命名，業內普遍默認的規范通常是以其中文名稱的每個漢字拼音首字母組成。考慮行業習慣和通常思路建議用：建議用于表示用戶業務應用屬性的數據項字段名采用中文拼音首字母命名，對于其它純粹用于應用系統內部使用的則盡量使用英文單詞進行命名。另外，當按中文名稱拼音首字母組合出來后出現與其它字段名重名時，則將最后命名的這個數據項的最后一個漢字用其完整拼音字母代替。 **?建議：同義性原則** 對于同一含義盡量使用相同的單詞命名，不管使用英文單詞、英文縮寫還是拼音首字母，以免引起誤解。如TELEPNHOE的A表中表示固定電話號碼，在B表中就不應該用于表示移動電話號碼。盡量避免同一單詞表示多種含義的情況。 **?建議：命名方式一致原則** 在一個系統、一個項目中盡量采用一致的命名方式，都采用英文單詞或者拼音首字母。尤其要避免在一個對象命名中同時采用英文單詞和拼音首字母。如確實需要在一個項目中采用兩種命名方式，考慮系統功能設計相關表（開發）使用英文單詞命名，業務相關的表（實施）使用拼音首字母。 **?建議：擴展性原則** 各系統或者項目在遵循本規范的基礎上可以根據需要制定更明確的規范細則，以滿足項目管理需要。如對模塊進行統一命名，然后用于表名的前綴。建議每個系統在啟動開發時建立數據字典，管理命名中使用的英文單詞、英文單詞縮寫、拼音首字母縮寫等，對用于命名的單詞進行統一管理。 ### 1.2 命名前綴規范 ?規范：以下對象命名采用固定前綴進行命名，前綴表示數據庫對象的類型，前綴代碼規范如下：  ### 1.3 表和列Tables and Table Columns 1.3.1 表 **?規范：表的命名以T_開頭**； 說明：公司一直以來對信息代碼表特殊規范以BM_（表碼）或者DM_（代碼）開頭，考慮歷史特殊情況信息代碼類表命名方式可以沿用歷史習慣。表碼表的規范名稱為信息代碼表，因此信息代碼表以后將統一使用DM_開頭。 **?規范：表名采用多段式命名，各單詞間用下劃線分隔； ?規范：表名只允許用英文字母、下劃線、數字進行命名，不允許用中文或者其他符號； ?規范：表名全部字母大寫； ?規范：根據歷史習慣各系統常用表類前綴作如下約定**  **?建議：表名也用于相關索引、分區、分區表空間、約束、主鍵等命名，因此為了避免相關對象命名長度超過限制，建議表名長度不要超過20。 ?建議：表的命名方式建議采用T_MOUDLE_ENTITY方式。MOUDLE表示數據庫對象所屬的系統、模塊名或者主題分類。ENTITY表示目的表代表的實體名稱。MOUDLE 只能由一個單詞組成，ENTITY可以根據需要有多個單詞組成。 ?建議：命名時應盡可能地使名稱能夠清晰準確表達對象的內容，盡可能使用能代表其含義的英文單詞、英文單詞縮寫，特殊情況也可采用拼音首字母**。 示例：T_UserInfo、USER_INFO、UserInfo、T_用戶信息、TB_USER_INFO、TBL_USER_INFO、T$USER$INFO、等都是違反本規范的，正確命名為T_USER_INFO。 **1.3.2 列 ?規范：列名無需使用前綴，如使用數據類型編碼作為前綴； ?規范：列名只允許用英文字母、下劃線、數字進行命名，不允許用中文或者其他符號； ?規范：列名字母全部大寫； ?規范：列名采用多段式命名時，各單詞間用下劃線分隔； ?規范：列名不能直接使用數據庫保留字； ?建議：列的命名應盡可能地采用簡潔明了的列名以準確描述列的內容含義, 根據需要可以一個單詞或者多個單詞進行命名； ?建議：日期類型字段推薦以“_DATE”結尾的名字命名，時間類型的字段推薦以“_TIME”結尾的名字命名。 ?建議：主鍵列命名為“ID”或者以 “_ID”為后綴進行命名。對于需要在其他表中引用的主鍵字段以“_ID”后綴方式命名，普通表主鍵無需加后綴。如基礎信息表的主鍵一般應命名為“ENTITIE_ID”方式，而通常業務數據明細表的主鍵則直接命名為“ID”。** 示例： 1\. 正確命名：USER_NAME、AUDIT_TIME、AUDIT_USER 2\. 錯誤命名：USERNAME、UserName、C_USER_NAME、人員姓名，違反規范。 3\. 錯誤命名：COMMENT、AUDIT，違反保留字 ### **1.4 視圖 Views** **?規范：視圖的命名以VW_開頭 ?規范：視圖其他命名規范與表名相同 ?建議：視圖的列名一般與基表一致，但是根據需要可以與基表的列名不同。如接口視圖一般根據接口需求進行命名**。 ### **1.5 索引Indexes** **?規范：普通索引名稱以IDX_為前綴，約束性索引命名參見約束章節說明。不區分B-TREE索引，位圖索引、函數索引等類型。 ?建議：單字段索引的命名方式為：IDX_表名_字段名，表名無須前綴，命名長度太長時表名和字段名可以考慮縮寫。 ?建議：多字段聯合索引命名方式同單字段，考慮長度限制，可以只列出主要字段名或者采用縮寫方式描述索引字段。** 示例： 1\. 錯誤命名：IDX_USER_INFO，沒有給出字段名 2\. 錯誤命名：B_USER_INFO_DEPT_CODE，前綴錯誤。 ### **1.6 表空間 Tablespace** **?規范：表空間名以TS_開頭 ?建議：公用（非分區表專用）表空間命名規范為：TS_系統名_類型名。類型分為：數據DATA,索引INDX，也可以根據需要增加其他分類。系統名一般與系統主用戶名一致，如門戶系統為PORTAL。 ?建議：分區表專用表空間命名規范為：TS_表名_分區編號。表名可以不用前綴，分區編號盡量使用能夠表示分區范圍的編號。如按年分區可以用2004表示2004年的分區。** 示例： 1\. 正確命名：TS_PORTAL_DATA、TS_PORTAL_INDX分別表示門戶系統的數據表空間和索引表空間。 2\. 錯誤命名：PORTAL_DATA（無前綴）、TS_Portal_indx（大小寫） ### **1.7 分區Partitions** **?建議：分區的命名規范為為PT_表名/索引名_Pn。其中，TNAME是指分區表或分區索引的名稱，n是用于區分不同分區的唯一識別標志。如果分區表是以年份的不同進行分區，則n為所代表的年份。** ### **1.8 用戶、模式 Scheme** **?規范：數據庫用戶采用一個代表系統名稱含義的英文單詞或者拼音首字母進行命名，無前綴。 ?規范：不得使用數據庫自動創建的用戶模式，如SYSTEM、SYS、ROOT等。 ?建議：創建數據庫用戶時一般不要授予DBA權限**。 ### 1.9 完整性約束Integrity Constraints **1.9.1 主鍵Primary Keys** ?建議：主鍵約束的命名格式為PK_表名，表名不帶前綴。如采用字段后加PRIMARY KEY方式添加主鍵則無需命名，由數據庫自動命名。 示例： 1\. 表T_SYS_MENU的主鍵約束命名為PK_SYS_MENU。 **1.9.2 外鍵Foreign Keys** ?建議：外鍵約束的命名格式為FK_表名_字段名，表名不用前綴，字段名較長時可以縮寫。 **1.9.3 唯一關鍵字約束Unique Keys** 建議：唯一關鍵字約束命名規范為UK_表名，表名可以不帶前綴。一般情況不會出現一個表除了主鍵外還有多個唯一約束的情況，確實需要時可以命名為UK_表名_n，n為索引區分標識可以是字段名或者序號。 **1.9.4 其他約束Other Constraints** 建議：CHECK約束的命名格式為CK_表名_字段名，表名可以不帶前綴，名字太長時表名和字段名可以根據需要縮寫。 ### **1.10 同義詞Synonyms** 建議：同義詞的目的是用于方便對其他用戶或者數據庫的對象的使用，因此同義詞在命名時，一般與原數據對象名稱相同，如需要前綴可采用SYN_。 ### **1.11 序列號Sequences** ?規范：序列號的命名應以SEQ_開頭 ?規范：序列號命名格式為SEQ_主鍵列名或者SEQ_表名。前者適用于主鍵列用有含義字母進行命名的，后者適用于直接用ID命名主鍵的情況。表名可以不用前綴。 示例： 1\. 正確命名：SEQ_ORDER_NO用于訂單表頭主鍵列ORDER_NO的序列號，SEQ_ORDER_DETAIL用于訂單明細表主鍵列ID的序列號。 2\. 錯誤命名：SQ_ORDER_NO、ORDER_NO、SEQ_order_no ### **1.12 包Packages** ?規范：包的命名以PKG_開頭 ?建議：包的命名格式PKG_MOUDLE，MOUDLE用代表模塊或者功能組的名字進行命名。建議在有可能的情況下盡量使用包。 示例： 1\. 正確命名：PKG_REPORT表示報表模塊的包名 2\. 錯誤命名：PK_REPORT，PK_前綴用于主鍵。REPORT_PKG，應使用前綴方式命名而不是后綴。Pkg_report，大小寫不符合規范。 ### 1.13 函數Functions ?規范：函數命名以F_開頭 ?建議：包中的函數的命名規范為F_NAME，NAME表示相應的功能用途描述；所屬的模塊或者功能組已經在函數所引用的包中指出。 ? 建議：獨立的函數的命名規范為F_MODULE_ NAME，MOUDLE可用于指明所屬的模塊的名稱或者功能組。對于基本功能函數，MOUDLE_可以不需要。 ### 1.14 存儲過程Procedures 1\. 規范：除了前綴改為“SP_”,其余與函數相同。 ### 1.15 參數Parameters、變量Variables 2.規范：輸入函數命名規范為P_NAME 3.規范：普通類型變量命名規范為V_NAME，如數字、字符串、日期等。CURSOR類型變量使用CUR_作為前綴。隱式游標變量、記錄類型變量以及對象類型變量按普通變量規范。 4.規范：輸出參數命名規范為O_NAME，輸出參數放在參數列表最后。 5\. 建議：命名規范中的NAME部分應能清楚表示變量或者參數的含義，以提高代碼可讀性。避免使用V_1、V_M、P_1、P_N等無法表達具體含義的參數或者變量命名。 示例： **[sql]**?[view plain](http://blog.csdn.net/houseq/article/details/39478687# "view plain")?[copy](http://blog.csdn.net/houseq/article/details/39478687# "copy") 1. 1.?正確變量命名：?? 2. DECLARE?? 3. V_ORDER_DATE?CHAR(8)；--訂單日期?? 4. V_ORDER_NO?NUMBER(16)；--訂單號?? 5. CURSOR?CUR_ORDER_LIST?IS?SELECT?……；?? 6. 2.?錯誤變量命名：?? 7. DECLARE?? 8. ORDER_DATE?CHAR(8);--沒有規定前綴?? 9. ORDER_NO?NUMBER(16);?--沒有規定前綴?? 10. v_order_detail_id?number(16);--大小寫不規范?? 11. 3.?正確參數命名：?? 12. CREATE?PROCEDURE?P_NAME(?? 13. P_USER_ID?VARCHAR2,--用戶編號?? 14. O_ORDER_COUNT?OUT?NUMBER—輸出訂單數?? 15. )?AS?……?? 16. 4.?錯誤參數命名：?? 17. CREATE?PROCEDURE?P_NAME(?? 18. USER_ID?VARCHAR2,--前綴不規范?? 19. P_dept_code?VARCHAR,--大小寫錯誤?? 20. P_2?OUT?NUMBER—前綴不規范，命名沒有含義?? 21. )?AS?……?? ### 1.16 觸發器 Triggers 規范：觸發器的命名規范為：TRG_表名_觸發器類型。表名不帶前綴，觸發器的類型由觸發時機和觸發動作組成：‘B’表示前觸發，‘A’表示后觸發，‘INSERT’‘UPDATE’‘DELETE’描述觸發動作。 示例： 1.正確命名：針對業務系統繳費表（前觸發）的觸發器的命名為TRG_BS_CHARGE_BINSERT。 2.錯誤命名：TRG_BS_CHARGE ,無規定后綴、BS_CHARGE_BINSERT,無規定前綴、TrgBsCharge,違法大小寫規定和分段命名原則；