一、概述

　　設計規範更多的是為了確保數據庫設計的合理性、為了項目最終的協調穩定性，而命名規範則更多的是為了確保設計的正式和統一。公正的講，數據庫中表字段等等以什麽樣的方式命名、取具體什麽名字，並不會直接影響到項目的穩定性。

　　制定規範的直接目的是約束設計行為，最終目的是確保設計的合理統一。規範雖然是有豐富項目經驗的人制定的，但維護的卻不是某個人的意誌，而是項目的意誌，因為遵守此規範對項目是好的有利的，此規範才有意義。所以規範是為了項目利益最大化而在團隊人員中形成的一種約定（貌似約定的英文單詞Convention本身就有規範的意思），所有參與設計的人員都要遵守此約定，所有參與開發的人員都會依此約定解讀設計。我們約定，所有的主鍵統一命名為id，結果有設計人員違反約定將一個非主鍵字段命名為id，約定被打破，共識也就被打破，設計人員之間、開發人員與設計人員之間的溝通就出現了隔閡。

　　設計規範更多的是為了合理，命名規範更多的是為了統一，團隊協作中，統一在某種程度上比局部設計開發的好壞更重要。違反了約定，局部設計開發的再好，反而可能影響到項目整體的穩定協調。

　　在“設計規範”中提到過一些命名規範，也詳細講述了表、字段的類型、註釋等屬性的設置，為什麽要求主鍵統一命名為id、統一為char(32)類型，為什麽要求浮點型數值統一為decimal類型？我們希望團隊中所有人看到設計成果，一眼就可以明白這個字段是做什麽的、代表的含義是什麽，可以但不止於見名知意。再者，當前的開發模式，前後端代碼及數據庫文檔、程序文檔、接口文檔等等大都是由工具生成，而其最底層的依據就是數據庫，表、字段的命名註釋同時會影響到工具生成的文檔、代碼中的類屬性方法甚至是前臺頁面的命名註釋，數據庫設計命名的規範關系到整個項目的規範。

二、編程中常用命名方式

　　a．匈牙利命名法。由微軟的一位匈牙利程序員Charles Simonyi提出，相對復雜，首字母小寫，基本原則是：變量名＝屬性＋類型＋對象描述，其中每一對象的名稱都要求有明確含義，可以取對象名字全稱或名字的一部分。匈牙利命名法主要在C或C++這種面向過程的程序語言中使用，如果用在Java、C#這種面向過程的語言中就很別扭。

　　b．Camel命名法。即駱駝式命名法，首字母小寫，采用該命名法的名稱看起來就像駱駝的駝峰一樣高低起伏。Camel命名法有兩種形式：

　　　　第一種是混合使用大小寫字母，例如englishName、fartherCode。在Java中，屬性名和方法名一般都采用這種命名方式，在C#中只有屬性名采用這種命名方式，我們在前面也規定，SQLServer中字段的命名也采用這種方式。

　　　　第二種是單詞之間加下劃線，例如english_name、farther_code。我們在前面規定，Oracel和MySQL表、字段的命名都采用這種方式，不過我們要求Oracle全部使用大寫字母，MySQL全部使用小寫字母。再者，無論是在Java還是C#，甚至是在JavaScript中，所有的常量，都使用這種命名方式，但和Oracle表字段的命名方式一樣要全部使用大寫字母，比如前面的設計規範中介紹數據字典表時，字典類型、字典項的編碼和文本信息需要即時獲取，以往的習慣在程序中建立一個常量類，所有用到的字典數據在裏面用常量標明，這時常量的命名方式即是如此。

　　c．Pascal命名法。即帕斯卡命名法，與Camel命名法類似，不過是首字母大寫。在C#中，類名和方法名一般采用這種命名方式，在Java中類名一般采用這種方式。在前面也規定，SQLServer中數據庫、表的命名也采用這種方式。

三、基本規範

1、命名規範

　　采用26個英文字母(區分大小寫)和0-9這十個自然數,加上下劃線‘_‘組成,共63個字符。組合而成的變量名即可。

　　數據庫及表名均不允許出現數字，字段名除非特殊情況不允許出現數字。

　　約定大於配置【Convention Over Configuration】

　　註意事項：

　　　　1) 以上命名都不得超過30個字符的系統限制.變量名的長度限制為29(不包括標識字符@).
　　　　2) 數據 對象、變量的命名都采用英文字符,單數形式，禁止使用中文命名.絕對不要在對象名的字符之間留空格.
　　　　3) 小心保留詞,要保證你的字段名沒有和保留詞、數據庫系統或者常用訪問方法沖突　　
　　　　4) 保持字段名和類型的一致性,在命名字段並為其指定數據類型的時候一定要保證一致性.假如數據類型在一個表裏是整數,那在另一個表裏可就別變成字符型了.
　　　　5）多對多關系表，以Mapping結尾，如XXMapping　　　　

2、命名長度限制

3、單詞縮寫

　　建議當表名超過15個字符、字段名超過20個字符時就應該嘗試用單詞縮寫重新命名，如果名稱長度在此之內，原則上講則盡可能不用縮寫以使表述具體清晰，表、字段最終的名稱長度要嚴格控制在30個字符以內。關於單詞縮寫規則如下：

　　a．如果可以在字典裏找到一個詞的縮寫，就用這個做為縮寫，比如：Monday=Mon、December=Dec，可在此網站下查找到一些英文單詞的縮寫：http://shortof.com/；

　　b．可以刪除單詞元音(詞首字母除外)和每個單詞的重復字母來縮寫一個單詞。比如：Current = Crnt、Address = Adr、Error = Err、Average = Avg；

　　c．對於主從表，如果主表名稱沒有縮寫而從表的名稱需要縮寫，則從表名稱從第二個單詞開始縮寫，第一個名詞盡可能和主表保持一致。比如企業基本信息表名稱為enterprise，則企業訴訟表enterprise_litigation可簡寫為enterprise_ltg，企業證書表enterprise_certificate可簡寫為enterprise_crt。最終的數據庫表及由數據庫表生成的程序在集成開發環境（IDE，Integrated Development Environment）中是按名稱排列的，這樣做是為了讓相似功能的表、類文件排列在一起，方便開發者操作。

四、推薦命名規則

1、命名方式

2、關於表前綴

　　a．系統表（S_）：System，系統配置相關的基本信息表。系統用戶表（S_USER）、系統角色表（S_ROLE）、系統菜單（S_LINK_MENU）、操作日誌（S_OPERATION_LOG）、登錄日誌（S_LOGIN_LOG）、系統字典（S_DICTIONARY）、系統字典類型（S_DICTIONARY_TYPE）等。

　　b．字典表（D_）：Dictionary，非系統字典外的字典表。在“設計規範”——“相關註釋”——“字典字段”中提到過字典表的定義，除了數據庫中的通用字典表，還有一些常見表，比如地區表（D_REGION）、ICD編碼（D_ICD）等，也是一種字典表，這裏的D_前綴即加在這類字典表名前面。

　　c．中間表（R_）：Relationship，多對多關系中間表。具體命名方式建議為：R_主表名_從表名，在多對多關系中其實不分主從表，這裏我們規定核心表為主表，另外一個為從表。比如用戶角色關系中，用戶表（S_USER）為主、角色（S_ROLE）表為從，那中間表就命名為R_USER_ROLE。當中間表名超長時，則根據實際情況縮寫主從表名，建議優先縮寫從表表名。

　　d．業務表（B_）：Business，核心業務涉及的基本信息表。這裏的業務是非系統配置業務相關的，比如登錄、註冊、權限這些業務涉及的表都是和系統配置相關的，前綴應該是S_，而非B_。比如在線商城的項目中訂單業務涉及的表即是核心業務表，會診系統中會診單業務涉及的表即是核心業務表，如果項目龐大，涉及業務較多，可以在B後面繼續加單字母區分不同的業務，BA_、BB_、BC_……，沒必要非得和某個英文對應，只是個代號，和項目組的人員說明即可。

3、關於字段命名

　　a．所有表中的主鍵統一命名為id，主鍵統一使用UUID，類型統一為char(32)。不建議使用復合主鍵，即便是在多對多關系的中間表中，還是建議用單獨的字段做主鍵，復合字段加惟一約束。

　　b．所有的表字段中，除外鍵，其它字段名都無需刻意加前後綴，也不要在字段名前出現表名。這裏的外鍵是廣義上的外鍵，不僅包括從表引用主表主鍵的外鍵字段，還包括存放主表相應關鍵信息的擴展字段。

　　比如病人表（Patient），主鍵就是id而不是pateint_id，名稱就是name而不是patient_name。但對於外鍵，比如其它表引用Patient表的主鍵那就是patient_id，對應Patient表的name字段那就是patient_name。如果一個表中有多個外鍵（字段）同時引用（對應）一張表的同一個字段，那再用其它標識。

　　c．對於字典字段，編碼字段後面跟Code後綴，文本字段跟Text後綴，比如gender_code、gender_text。

　　d．本規範中要求所有表示日期時間的字段，都要有後綴，如果只精確到天則以date為後綴，如果要精確到時分秒那就用datetime作後綴。要求日期時間類型的字段，盡可能精確到時分秒，即便是像生日（birth_date）這種字段，一般只存儲到年月日，但在選擇字段類型時建議還是為datetime而非date。所以這裏的後綴並不是和具體字段類型對應，而是根據實際業務情況，這個字段存儲的數據多是精確到年月日還是時分秒，則後綴相應的為date或datetime。

　　註：日期時間盡量減少使用time做後綴，因為time還有一個很常用的意思，就是次數。比如登錄日誌表中有用戶最後一次登錄時間字段login_time，不去看表的內容，很容易將login_time理解成登錄的次數。

　　e．本規範中建議是否註銷、是否成功等類似的布爾型字段，名稱前統一加is前綴，比如是否成功（is_success）、是否註銷（is_active）、是否顯示（is_display）等。

　　f.用盡量少的存儲空間來存數一個字段的數據;例如：能使用int就不要使用varchar、char,能用varchar(16)就不要使用varchar(256);

　　　　IP地址最好使用int類型;
　　　　固定長度的類型最好使用char,例如：郵編;能使用tinyint就不要使用smallint,int;
　　　　最好給每個字段一個默認值,最好不能為null;

4、關於約束控制命名　　

　　唯一性和主鍵約束、外鍵約束、檢查約束、空值約束、默認值約束

　　外鍵約束：以fk做前綴，後跟從表名稱和主表名稱：fk_從表名_主表名。

五、查看字符編碼

mysql

show Collation;
-- 查看數據庫的編碼方式
show variables like ‘character%‘; 
-- 數據庫編碼
show variables like ‘collation%‘; 

　　建議：MySQL數據庫中將Character Set設置為utf8、將Collation設置為utf8_bin，並在數據庫配置文件中設置lower_case_table_names=1，

六、數據庫範式

　　第一範式(1NF)：字段值具有原子性,不能再分(所有關系型數據庫系統都滿足第一範式);
　　　　例如：姓名字段,其中姓和名是一個整體,如果區分姓和名那麽必須設立兩個獨立字段;

　　第二範式(2NF)：一個表必須有主鍵,即每行數據都能被唯一的區分;
　　　　備註：必須先滿足第一範式;

　　第三範式(3NF)：一個表中不能包涵其他相關表中非關鍵字段的信息,即數據表不能有沈余字段;
　　　　備註：必須先滿足第二範式;

　　備註：往往我們在設計表中不能遵守第三範式,因為合理的沈余字段將會給我們減少join的查詢;
　　　　例如：相冊表中會添加圖片的點擊數字段,在相冊圖片表中也會添加圖片的點擊數字段;

002-數據庫命名開發規範