SQL Server 數(shù)據(jù)庫對象命名參考

一、?引言

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

NOTE：雖然這篇文章名為“數(shù)據(jù)庫對象命名參考”，實際上，在這篇文章中我不僅介紹了數(shù)據(jù)庫命名的規(guī)則，連帶講述了在數(shù)據(jù)庫設(shè)計與開發(fā)時所需要注意的幾個問題。

二、?基本命名規(guī)則

表1. 基本數(shù)據(jù)庫對象命名

數(shù)據(jù)庫對象

前綴

舉例

表(Table)
字段(Column)
視圖(View)
存儲過程(Stored procedure)
觸發(fā)器(Trigger)
索引(Index)
主鍵(Primary key)
外鍵(Foreign key)
Check約束(Check Constraint)
Unique約束
用戶定義數(shù)據(jù)類型(User-defined data type)
用戶定義函數(shù)(User-defined function)

無
無
v
pr
tr
ix_
pk_
fk_
ck_
uq_
udt
fn

Student
Title
vActivity
prDelOrder
trOrder_D
ix_CustomerID
pk_Admin
fk_Order_OrderType
ck_TableColumn
uq_TableColumn
udtPhone
fnDueDate

三、?關(guān)于命名的約定

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

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

好的命名

不好的命名

@CurrentDate
@ActivityCount
@EquipmentType
prCalculateTotalPrice

@D
@ActNum
@ET
@prRunCalc

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

如果完全根據(jù)上一條的要求，那么根據(jù)業(yè)務(wù)描述的過程名可能會變得很冗長，比如下面：

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

prGetParentOrganizationalUnitName (獲取上級單位名稱)

此時則應(yīng)該考慮使用縮寫：

·??????如果可以在字典里找到一個詞的縮寫，就用這個做為縮寫，比如：Mon(Monday)、Dec(December)

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

·??????不要使用有歧異的縮寫(一般是語音上的歧義)。比如b4(before)、xqt(execute)，4tran(Fortran)

四、?表格、字段的命名： 1.??單數(shù)表名、字段名?還是復(fù)數(shù)表名、字段名？

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

主張用復(fù)數(shù)表名的陣營認(rèn)為：表是由一組記錄構(gòu)成的，所以應(yīng)當(dāng)使用復(fù)數(shù)名詞來命名它。他們經(jīng)常使用的理由是：客戶表是客戶們的集合，而集合意味著多個，因此應(yīng)當(dāng)稱他們?yōu)镃ustomers表。除非你只有一個客戶，但這種情況你根本用不著數(shù)據(jù)庫。

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

2.??避免無謂的表格后綴

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

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

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

3.??多對多關(guān)系中連接表的命名

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

4.??約定俗成的字段名前/后綴

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

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

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

為了避免這種情況發(fā)生，應(yīng)該明確的規(guī)定：所有表示時間的字段，統(tǒng)一以 Date 來作為結(jié)尾。

我們經(jīng)常需要統(tǒng)計發(fā)帖數(shù)、回帖數(shù)信息，這時候，開發(fā)人員通常會這樣去命名字段：PostAmount、PostTime、PostCount，同樣，由于Time的歧義，我們首先排除掉不使用PostTime作為字段名。接下來，Amount 和 Count 都可以表示計數(shù)的意思，用哪個合適呢？這里，我推薦使用Count。為什么呢？如果你做過Asp開發(fā)，相信一定知道 RecordCount 這個屬性，命名的時候有一個原則：就是使用約定俗成的名稱，而不要去自創(chuàng)名稱。既然微軟都用Count后綴來表示數(shù)目，我們?yōu)槭裁床荒兀?/p>

于是，所有表示數(shù)目的字段，都應(yīng)該以Count作為結(jié)尾。將這一概念做以推廣，很容易得出，瀏覽次數(shù)為 ViewCount，登錄次數(shù)為LoginCount 等等。

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

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

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

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

5.??字段命名時需注意的一個問題

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

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

五、?建表時需要注意的問題 1.??數(shù)據(jù)庫不僅是用來保存數(shù)據(jù)，還應(yīng)負(fù)責(zé)維護(hù)數(shù)據(jù)的完整性和一致性

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

在這里，我提出如下數(shù)據(jù)庫設(shè)計的建議：

1.?????如果要寫代碼來確保表中的行都是唯一的，就為表添加一個主鍵。

2.?????如果要寫代碼來確保表中的一個單獨的列是唯一的，就為表添加一個約束。

3.?????如果要寫代碼確定表中的列的取值只能屬于某個范圍，就添加一個Check約束。

4.?????如果要寫代碼來連接父－子 表，就創(chuàng)建一個關(guān)系。

5.?????如果要寫代碼來維護(hù)“一旦父表中的一行發(fā)生變化，連帶變更子表中的相關(guān)行”，就啟用級聯(lián)刪除和更新。

6.?????如果要調(diào)用大量的Join來進(jìn)行一個查詢，就創(chuàng)建一個視圖。

7.?????如果要逐條的寫數(shù)據(jù)庫操作的語句來完成一個業(yè)務(wù)規(guī)則，就使用存儲過程。

NOTE：這里我沒有提到觸發(fā)器，實踐證明觸發(fā)器會使數(shù)據(jù)庫迅速變得過于復(fù)雜，更重要的是觸發(fā)器難以調(diào)試，如果不小心建了個連環(huán)觸發(fā)器，就更讓人頭疼了，所以我更傾向于根本就不使用觸發(fā)器。

2.??以Not Null的思路建表

我發(fā)現(xiàn)很多開發(fā)人員在建表的時候，如果要新建一個字段，他的思路是這樣的：默認(rèn)這個字段是可以為Null的，然后去判斷是不是非要Not Null不可，如果不是這樣，OK，這個字段可以為Null，接著繼續(xù)進(jìn)行下一個字段。結(jié)果往往是一張表除了主鍵以外所有的字段都可以為Null。

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

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

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

Select Null + 5 As Result

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

ColumnName??? Varchar(50) NotNull Constraint ck_ColumnName Check(Len(ColumnName) > 0)

所以，合理的思維方式應(yīng)該是這樣的：默認(rèn)這個字段是 Not Null的，然后判斷這個字段是不是非為Null不可，如果不是這樣，OK，這個字段是Not Null的，進(jìn)行下一個字段。

3.??一個建表的范例腳本

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

Create Table Article
(
IdInt Identity(1,1) Not Null,
Title?? Varchar(50) Not Null Constraint uq_ArticleTitle Unique,
KeywordsVarchar(50) Not Null,
AbstractVarchar(500)Not Null,
Author? Varchar(50) Not Null Default '張子陽',
Type??? TinyInt???? Not Null Default 0Constraint ck_ArticleType Check(Type in (0,1,2)),? -- 0,原創(chuàng)；1,編譯；2,翻譯
IsOnIndex???? Bit?? Not Null Default1,?? -- 是否顯示在首頁
Content Text? Not Null,
SourceCode??? Varchar(100)Null,? -- 程序源碼的下載路徑
Source? Varchar(50) Not Null Default 'TraceFact',?? -- 文章出處
SrcUrl? Varchar(150)Null,? -- 文章出處的URL
PostDateDateTime??? 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 約束的命名規(guī)則：盡管Check約束是針對字段的，但在同一數(shù)據(jù)庫中，卻不能有同名的Check約束。所以，建議使用 ck_ + 表名 + 字段名 來命名它，比如這個范例腳本中的 ck_ArticleType。

除此以外，我還使用了Unique約束，以確保文章標(biāo)題的唯一性。由于這是我的博客文章表，不應(yīng)該出現(xiàn)重復(fù)的題目，這樣可以避免在使用 Insert 語句時插入重復(fù)值。類似于Check約束，這里的命名規(guī)則是：uq_ + 表名 + 字段名。

六、?主鍵的命名

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

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

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

七、?外鍵的命名

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

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

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

在實現(xiàn)外鍵的時候我們可以這樣寫：

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：在創(chuàng)建數(shù)據(jù)庫表的時候，一般需要寫成三個SQL腳本文件。第一個文件僅包含所有的創(chuàng)建表的SQL語句，即Create Table 語句。第二個文件包含刪除關(guān)系和表的語句，其中，所有刪除關(guān)系的語句，即Drop Constraint 語句集中在這個文件的上半部分，所有刪除表的語句，DropTable語句，集中在這個文件的下半部分。第三個文件包含建立表之間關(guān)系的語句。這種做法會在你移植數(shù)據(jù)庫的時候產(chǎn)生較大的便利，原因我就不解釋了，您一試便知。

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

建立解析表StudentCourse與Student表的外鍵關(guān)系：

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

建立解析表StudentCourse與Course 表的外鍵關(guān)系:

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

八、?觸發(fā)器的命名

由三部分構(gòu)成：

1.?????前綴(tr),描述了數(shù)據(jù)庫對象的類型。

2.?????基本部分，描述觸發(fā)器所加的表。

3.?????后綴(_I、_U、_D)，顯示了修改語句(Insert, Update及Delete)

九、?存儲過程的命名

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

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

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

1.?????動詞放前面，名詞放后面。

2.?????名詞放前面，動詞放后面。

我個人推薦使用方式2，現(xiàn)在說說原因：

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

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

這時，你用企業(yè)管理器查看時，會發(fā)現(xiàn)存儲過程像下面這樣整整齊齊的排列：

prEmployeeDelById
prEmployeeGetById
prEmployeeInsert
prEmployeeUpdate
prProductDelById
prProductGetById
prProductInsert
prProductUpdate

很容易就會發(fā)現(xiàn)，當(dāng)你的存儲過程越多時，這種命名方法的優(yōu)勢就越明顯。

1.??存儲過程中參數(shù)的命名

存儲過程中的入口參數(shù)，我建議與其對應(yīng)的字段名相同，這里，假設(shè)要寫一個更新Northwind數(shù)據(jù)庫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 ‘更新用戶失敗’

十、?總結(jié)

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

接著我按照表、字段、主鍵、外鍵、觸發(fā)器、存儲過程的順序，詳細(xì)講述了數(shù)據(jù)庫對象命名的規(guī)則。

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

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

?