引言

編碼規範是一個優秀程序員的必備素質，然而，有很多人非常註重程序中變量、方法、類的命名，卻忽視了同樣重要的數據庫對象命名。這篇文章結合許多技術文章和資料，以及我自己的開發經驗，對數據庫對象的命名規則提出了一點建議，希望能為大家提供一些參考。

NOTE：雖然這篇文章名為“數據庫對象命名參考”，實際上，在這篇文章中不僅介紹了數據庫命名的規則，還講述了在數據庫設計與開發時所需要註意的幾個問題。

基本命名規則

表1. 基本數據庫對象命名

關於命名的約定

變量(T-SQL編程中聲明的變量)、過程(存儲過程或觸發器等)、實體(表、字段)應該根據他們所代表的實體意義和進程作用來命名：

表2.好的命名 和 不好的命名 範例

還有一個常見的錯誤就是只使用面向計算機的術語，而不是面向公司業務的術語，比如ProcessRecord就是一個含糊不清的命名，應該使用一個進程業務描述來替換它，比如CompleteOrder.

如果完全根據上一條的要求，那麽根據業務描述的過程名可能會變得很冗長，比如下面：

prCountTotalAmountOfMonthlyPayments (計算每月付費的總金額)

prGetParentOrganizationalUnitName (獲取上級單位名稱)

此時則應該考慮使用縮寫：

• 如果可以在字典裏找到一個詞的縮寫，就用這個做為縮寫，比如：Mon(Monday)、Dec(December)
• 可以刪除單詞元音(詞首字母除外)和每個單詞的重復字母來縮寫一個單詞。比如：Current = Crnt、Address = Adr、Error = Err、Average = Avg
• 不要使用有歧異的縮寫(一般是語音上的歧義)。比如b4(before)、xqt(execute)，4tran(Fortran)

表格、字段的命名：

單數表名、字段名 還是 復數表名、字段名？

可能大家很少會考慮到給表名起單數還是復數，比如，對存儲客人信息的表，我們應該起Customer，還是Customers？我主張起單數表名，下面是來自《SQL Server 2000 寶典》的一段引用：

主張用復數表名的陣營認為：表是由一組記錄構成的，所以應當使用復數名詞來命名它。他們經常使用的理由是：客戶表是客戶們的集合，而集合意味著多個，因此應當稱他們為Customers表。除非你只有一個客戶，但這種情況你根本用不著數據庫。

根據筆者的非正式調查，有3/4的SQL Server開發人員支持使用單數命名。這些開發人員認為，客戶表是客戶的集合，而不是客戶們的集合。一組行不應當也不會被成為rows set(行們的集合)，而會被稱為row set(行集)。並且，通常在討論時人們會使用單數名稱來稱呼表，說Customer表比說Customers表聽起來更為清晰。

避免無謂的表格後綴

這兩點我想大家都知道：1、表是用來存儲數據信息的。2、表是行的集合。那麽如果表名已經能夠很好地說明其包含的數據信息，就不需要再添加體現上面兩點的後綴了。

實際工作中，我看到有的同事對表這樣命名：GuestInfo，用於存儲客戶信息。這個命名與上面所說的第1點重復，誰都知道表本來就是存儲信息(information)的，再加個Info無異於畫蛇添足，個人認為直接用Guest做表名就可以了。

對於存儲航班信息的表，他又命名為FlightList。這個命名又與之前說的第2點相重復，表是行的集合，那麽自然是列表(List)，加上List後綴顯得很多余，命名為 Flight 不是很好麽？可見，他給自己都沒有訂立一個明確的命名規則，不然這兩個表一定是要麽命名為：GuestList、FlightList 要麽命名為 GuestInfo、FlightInfo，而不會是兩者的混合。

多對多關系中連接表的命名

大家知道，如果要實現兩個實體間的多對多關系，需要三張表，其中一張是解析表。考慮下面這樣一個多對多關系，這是一個經典的學生選課問題：一個學生可以選很多門課，一門課可以有很多學生。此時為了實現上面的關系，就需要一張解析表(這張表只存儲學生ID和課程ID，而學生的信息和課程信息分別存在各自的表中)，這個表的起名，建議的寫法是將兩個表的表名合並(如果表名比較長可做簡化)，此處如 StudentCourse。這個表中字段分別命名為StudentId、CourseID(既是此表的復合主鍵，同時分別為連接Student表和Course表的外鍵，等下到主鍵和外鍵的命名處再說)，這樣就實現了學生和課程之間的多對多關系，當然，這個關系還可以加點額外的東西，比如給StudentCourse表中加AccessLevel字段，值域D{只讀,完全,禁止}，就可以實現訪問級別。

約定俗成的字段名前/後綴

數據庫開發的時間久了，慢慢就會摸索出一個規律來：就是很多的字段都有些共同的特性。比如說，有的字段是代表時間的(例如發帖時間，評論時間)，有的是代表數量的(例如瀏覽數，評論數)，有的是代表真假類型的(例如是否將博客隨筆顯示在首頁)。對於這種同一類型的字段，應該使用統一的 前綴 或者 後綴去標識它。

我們來舉幾個例子看得更明白一點。

以大家都熟悉的論壇來說，需要記錄會員最後一次登錄的時間，這時候一般人都會把這個字段命名為LoginTime 或者 LoginDate。這時候，已經產生了一個歧義：對於另一名開發者來說，如果僅看表的字段名稱，不去看表的內容，很容易將LoginTime理解成 登錄的次數，因為，Time還有一個很常用的意思，就是次數。

為了避免這種情況發生，應該明確的規定：所有表示時間的字段，統一以 Date 來作為結尾。

我們經常需要統計發帖數、回帖數信息，這時候，開發人員通常會這樣去命名字段：PostAmount、PostTime、PostCount，同樣，由於Time的歧義，我們首先排除掉不使用PostTime作為字段名。接下來，Amount 和 Count 都可以表示計數的意思，用哪個合適呢？這裏，我推薦使用Count。為什麽呢？如果你做過Asp開發，相信一定知道 RecordCount 這個屬性，命名的時候有一個原則：就是使用約定俗成的名稱，而不要去自創名稱。既然微軟都用Count後綴來表示數目，我們為什麽不呢？

於是，所有表示數目的字段，都應該以Count作為結尾。將這一概念做以推廣，很容易得出，瀏覽次數為 ViewCount，登錄次數為LoginCount 等等。

再舉一個例子，我們很少在數據庫裏直接保存圖片等二進制數據，通常是僅保存圖片的URL路徑；在文章管理系統中，如果是轉載文章，也會用到記錄文章出處的字段。個人建議所有代表鏈接的字段，均為Url結尾。於是，圖片路徑的字段命名為 ImageUrl，文章出處字段的命名為SourceUrl。

最後一個例子，我們經常需要用到布爾值，比方說，這篇隨筆要不要顯示到首頁，這篇隨筆是不是保存到草稿箱等等。同樣，按照微軟的建議，布爾類型的值均以 Is、Has 或者 Can開頭。

如果讓我來建表示是否將隨筆放到首頁的字段，它的名字一定是這樣的：IsOnIndex

類似的例子是很多的，我在這裏僅舉出典型的幾個範例，大家可以自行拓展，如果我能起到一個拋磚引玉的作用就很滿足了。

字段命名時需註意的一個問題

我發現有很多開發人員喜歡給字段加上表名作為它的前綴，舉個例子，如果有個表叫User，那麽他就會將這個表中的字段命名為：UserId、UserPassword、UserName、UserPhone　等等。個人認為，這是沒有必要的，因為你已經確切的知道了這個表存儲的是User的信息，那麽其中的字段必然是針對於User的。而且，在Join連接操作中，你的SQL代碼看上去也會更加的精簡一些，諸如　[User].UserName = Aritcle.ArticleAuthor 這樣的代碼完全可以實現為　[User].Name = Article.Author。

這裏還存在一個特例，就是表的外鍵包含的字段。在這種情況下，我傾向於使用表名+ID　的方式，比如　CategoryId 、UserId 等。假設有表Article，那麽它的主鍵我會命名為Id，關聯用戶表User的外鍵包含的字段，我會命名為UserId。之所以這樣，是因為在語言(比如C#)中創建對象時，有時候會使用代碼生成器(根據數據庫的字段名生成對象的字段、屬性名)，此時生成的代碼更規整一些。

建表時需要註意的問題

數據庫不僅是用來保存數據，還應負責維護數據的完整性和一致性

我看過很多的開發人員設計出來的數據庫，給我的感覺就是：在他們眼裏，數據庫的作用就如同它的名稱一樣――僅僅是用來存放數據的，除了不得不建的主鍵以外，什麽都沒有...沒有 Check約束，沒有索引，沒有外鍵約束，沒有視圖，甚至沒有存儲過程。

在這裏，我提出如下數據庫設計的建議：

1. 如果要寫代碼來確保表中的行都是唯一的，就為表添加一個主鍵。
2. 如果要寫代碼來確保表中的一個單獨的列是唯一的，就為表添加一個約束。
3. 如果要寫代碼確定表中的列的取值只能屬於某個範圍，就添加一個Check約束。
4. 如果要寫代碼來連接 父－子 表，就創建一個關系。
5. 如果要寫代碼來維護“一旦父表中的一行發生變化，連帶變更子表中的相關行”，就啟用級聯刪除和更新。
6. 如果要調用大量的Join來進行一個查詢，就創建一個視圖。
7. 如果要逐條的寫數據庫操作的語句來完成一個業務規則，就使用存儲過程。

NOTE：這裏我沒有提到觸發器，實踐證明觸發器會使數據庫迅速變得過於復雜，更重要的是觸發器難以調試，如果不小心建了個連環觸發器，就更讓人頭疼了，所以我更傾向於根本就不使用觸發器。

以Not Null的思路建表

我發現很多開發人員在建表的時候，如果要新建一個字段，他的思路是這樣的：默認這個字段是可以為Null的，然後去判斷是不是非要Not Null不可，如果不是這樣，OK，這個字段可以為Null，接著繼續進行下一個字段。結果往往是一張表除了主鍵以外所有的字段都可以為Null。

之所以會有這樣的思路，是因為Null好啊，程序不容易出錯啊，你插入記錄的時候如果不小心忘輸了一個字段，程序依然可以Run，而不會出現 “XX字段不能為Null”的錯誤消息。

但是，這樣做的結果卻是很嚴重的，也會使你的程序變得更加繁瑣，你不得不進行一些無謂的空值處理，以避免程序出錯。更糟的是，如果一些重要數據，比如說訂單的某一項值為Null了，那麽大家知道，任何值與Null相操作(比如加減乘除)，結果都是Null，導致的結果就是訂單的總金額也為Null。

你可以運行下面的代碼嘗試一下：

Select Null + 5 As Result

你可能會說，就算我將字段設置成Not Null，但是它依然可以接受空字符串，這樣一來在程序中還是要進行空值處理。請別忘了，數據庫還賦予你一個強力武器，就是 Check 約束，當你需要確保一個字段既不可以為Null，又不可以為空的時候，可以這麽寫：

ColumnName    Varchar(50)       Not Null Constraint ck_ColumnName Check(Len(ColumnName) > 0)

所以，合理的思維方式應該是這樣的：默認這個字段是 Not Null的，然後判斷這個字段是不是非為Null不可，如果不是這樣，OK，這個字段是Not Null的，進行下一個字段。

一個建表的範例腳本

我正在建立我自己的個人空間，其中的文章表是這樣寫的：

Create Table Article
(
    Id            Int Identity(1,1) Not Null,
    Title         Varchar(50)       Not Null Constraint uq_ArticleTitle Unique,
    Keywords      Varchar(50)       Not Null,
    Abstract      Varchar(500)      Not Null,
    Author        Varchar(50)       Not Null Default ‘張子陽‘,
    Type          TinyInt           Not Null Default 0 Constraint ck_ArticleType Check(Type in (0,1,2)),  -- 0,原創；1,編譯；2,翻譯
    IsOnIndex     Bit               Not Null Default 1,   -- 是否顯示在首頁
    Content       Text              Not Null,
    SourceCode    Varchar(100)      Null,  -- 程序源碼的下載路徑
    Source        Varchar(50)       Not Null Default ‘TraceFact‘,   -- 文章出處
    SrcUrl        Varchar(150)      Null,  -- 文章出處的URL
    PostDate      DateTime          Not Null Default GetDate(),
    ViewCount     Int               Not Null Default 0,
    ClassId       Int               Not Null   -- 外鍵包含的字段，文章類別

    Constraint pk_Article Primary Key(Id)   -- 建立主鍵
)

可以看到，在這裏我使用了 Check 約束，以確保文章類型只能為 0,1,2。這裏，我想說的是Check 約束的命名規則：盡管Check約束是針對字段的，但在同一數據庫中，卻不能有同名的Check約束。所以，建議使用 ck_ + 表名 + 字段名 來命名它，比如這個範例腳本中的 ck_ArticleType。

除此以外，我還使用了Unique約束，以確保文章標題的唯一性。由於這是我的博客文章表，不應該出現重復的題目，這樣可以避免在使用 Insert 語句時插入重復值。類似於Check約束，這裏的命名規則是：uq_ + 表名 + 字段名。

主鍵的命名

按照SQL Server 的默認規範(使用企業管理器創建主鍵時默認產生的主鍵名)，主鍵的命名為 pk_TableName。主鍵是針對一個表的，而不是針對一個字段的，大家有時候在企業管理器中會見到一個表的兩個字段前面都會有鑰匙的圖標(比如SQL Server 2000自帶的NorthWind範例數據庫的EmployeeTerritories表)，就會誤以為主鍵是針對字段的，即是說一個表上有兩個主鍵，其實錯了，只有一個主鍵，但包含了兩個字段，這就是常說的復合主鍵。為了有個更生動的認識，看下建立復合主鍵的SQL語句，以上面說到的多對多連接表StudentCourse為例：

Alter Table StudentCourse
Add Constraint pk_StudentCourse Primary key(StudentId, CourseId)

可見，對於主鍵pk_StudentCourse，包含了兩個字段StudentId 和 CourseId。

外鍵的命名

外鍵的命名為 fk_外鍵所在的表名_外鍵引用的表名。因為外鍵所在的表為從表，所以上式可以寫為 fk_從表名_主表名。

外鍵包含的字段的命名，外鍵包含的字段和外鍵是完全不同的概念。外鍵包含字段的命名，建議為：外鍵所在的表名 + Id。

考慮這樣一個關系，表Hotel，字段Id, Name, CityId。表City,字段Id,Name。因為一個城市可能有好多家酒店，所以是一個一對多的關系，City是主表(1方)，Hotel是從表(多方)。在Hotel表中，CityId是做為外鍵使用。

在實現外鍵的時候我們可以這樣寫：

Alter Table HotelInfo
Add Constraint fk_HotelInfo_City Foreign Key (CityID) References City(ID)
On Delete No Action On update No Action

很明顯，fk_HotelInfo_City是外鍵的名字，CityId是外鍵包含的字段的名字。

NOTE：在創建數據庫表的時候，一般需要寫成三個SQL腳本文件。第一個文件僅包含所有的創建表的SQL語句，即Create Table 語句。第二個文件包含刪除關系和表的語句，其中，所有刪除關系的語句，即Drop Constraint 語句集中在這個文件的上半部分，所有刪除表的語句，Drop Table語句，集中在這個文件的下半部分。第三個文件包含建立表之間關系的語句。這種做法會在你移植數據庫的時候產生較大的便利，原因我就不解釋了，您一試便知。

而對於多對多關系中解析表的外鍵包含的字段，順理往下推，我們可以這樣寫(再次回到學生選課的多對多例子中)：

建立解析表StudentCourse與Student表的外鍵關系：

Alter Table StudentCourse
Add Constraint fk_StudentCourse_Student Foreign Key (StudentId) References Student (Id)
On Delete No Action On Update No Action

建立解析表StudentCourse與Course 表的外鍵關系:

Alter Table StudentCourse
Add Constraint fk_StudentCourse_Course Foreign Key (CourseId) References Course(Id)
On Delete No Action On Update No Action

觸發器的命名

由三部分構成：

1. 前綴(tr),描述了數據庫對象的類型。
2. 基本部分，描述觸發器所加的表。
3. 後綴(_I、_U、_D)，顯示了修改語句(Insert, Update及Delete)

存儲過程的命名

大家知道，系統存儲過程的前綴是 sp_，為了避免將用戶存儲過程與系統存儲過程混淆，這裏我推薦大家使用 pr 作為自己定義的存儲過程的命名。

同時，命名的規則是：采用自解釋型的命名，比如：prGetItemById。

這裏，有個有意思的地方值得深思。我們按上面規則命名存儲過程的時候，可以用兩種方式：

1. 動詞放前面，名詞放後面。
2. 名詞放前面，動詞放後面。

我個人推薦使用方式2，現在說說原因：

以NorthWind 為例，假如對於 Employees 表你有4個存儲過程，分別命名為：prEmployeeInsert、prEmployeeUpdate、prEmployeeDelById、prEmployeeGetById

同時對於 Products 表你有類似的4個存儲過程，分別命名為：prProductInsert、prProductUpdate、prProductDelById、prProductGetById

這時，你用企業管理器查看時，會發現存儲過程像下面這樣整整齊齊的排列：

prEmployeeDelById
prEmployeeGetById
prEmployeeInsert
prEmployeeUpdate
prProductDelById
prProductGetById
prProductInsert
prProductUpdate

很容易就會發現，當你的存儲過程越多時，這種命名方法的優勢就越明顯。

存儲過程中參數的命名

存儲過程中的入口參數，我建議與其對應的字段名相同，這裏，假設要寫一個更新Northwind數據庫Employees表的存儲過程(做了簡化)，可以這麽寫：

Create Procedure prEmployeeUpdateById
    @EmployeeId       Int,
    @LastName     NVarchar(20),
    @FirstName    NVarchar(10)
As
    Update Employees Set
       LastName = @LastName,
       FirstName = @FirstName
    Where
       EmployeeId = @EmployeeId

    If @@error <> 0 or @@RowCount = 0
       Raiserror 16001 ‘更新用戶失敗’

總結

在這篇文章中，我首先提出了開發人員對數據庫對象命名不夠重視的問題，隨後列出了一張數據對象命名的簡表。

接著我按照 表、字段、主鍵、外鍵、觸發器、存儲過程的順序，詳細講述了數據庫對象命名的規則。

其間，我還穿插著講述了在數據庫開發中常見的一些問題，包括建表時需要註意的問題，以及在管理存儲過程時可以采取的技巧。

希望這篇文章能給你帶來幫助。

數據庫對象命名參考