對(duì)于一個(gè)大項(xiàng)目來(lái)講，數(shù)據(jù)庫(kù)的設(shè)計(jì)命名規(guī)范是很重要的一個(gè)環(huán)節(jié)，好的表設(shè)計(jì)，讓人看得很舒服，一看就明白是什么意思了，下面看到一篇很不錯(cuò)的數(shù)據(jù)庫(kù)對(duì)象命名參考文檔，所以整理分享給大家。

引言

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

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

基本命名規(guī)則

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

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

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

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

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

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

prCountTotalAmountOfMonthlyPayments (計(jì)算每月付費(fèi)的總金額)

prGetParentOrganizationalUnitName (獲取上級(jí)單位名稱(chēng))

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

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

表格、字段的命名：

單數(shù)表名、字段名 還是 復(fù)數(shù)表名、字段名？

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

避免無(wú)謂的表格后綴

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

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

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

多對(duì)多關(guān)系中連接表的命名

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

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

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

我們來(lái)舉幾個(gè)例子看得更明白一點(diǎn)。

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

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

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

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

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

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

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

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

字段命名時(shí)需注意的一個(gè)問(wèn)題

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

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

建表時(shí)需要注意的問(wèn)題

數(shù)據(jù)庫(kù)不僅是用來(lái)保存數(shù)據(jù)，還應(yīng)負(fù)責(zé)維護(hù)數(shù)據(jù)的完整性和一致性

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

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

1. 如果要寫(xiě)代碼來(lái)確保表中的行都是唯一的，就為表添加一個(gè)主鍵。
2. 如果要寫(xiě)代碼來(lái)確保表中的一個(gè)單獨(dú)的列是唯一的，就為表添加一個(gè)約束。
3. 如果要寫(xiě)代碼確定表中的列的取值只能屬于某個(gè)范圍，就添加一個(gè)Check約束。
4. 如果要寫(xiě)代碼來(lái)連接 父－子 表，就創(chuàng)建一個(gè)關(guān)系。
5. 如果要寫(xiě)代碼來(lái)維護(hù)“一旦父表中的一行發(fā)生變化，連帶變更子表中的相關(guān)行”，就啟用級(jí)聯(lián)刪除和更新。
6. 如果要調(diào)用大量的Join來(lái)進(jìn)行一個(gè)查詢(xún)，就創(chuàng)建一個(gè)視圖。
7. 如果要逐條的寫(xiě)數(shù)據(jù)庫(kù)操作的語(yǔ)句來(lái)完成一個(gè)業(yè)務(wù)規(guī)則，就使用存儲(chǔ)過(guò)程。

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

以Not Null的思路建表

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

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

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

你可以運(yùn)行下面的代碼嘗試一下：

Select Null + 5 As Result

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

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

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

一個(gè)建表的范例腳本

我正在建立我自己的個(gè)人空間，其中的文章表是這樣寫(xiě)的：

    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 '張子陽(yáng)',
    Type          TinyInt           Not Null Default 0 Constraint ck_ArticleType Check(Type in (0,1,2)),  -- 0,原創(chuàng)；1,編譯；2,翻譯
    IsOnIndex     Bit               Not Null Default 1,   -- 是否顯示在首頁(yè)
    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   -- 外鍵包含的字段，文章類(lèi)別

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

可以看到，在這里我使用了 Check 約束，以確保文章類(lèi)型只能為 0,1,2。這里，我想說(shuō)的是Check 約束的命名規(guī)則：盡管Check約束是針對(duì)字段的，但在同一數(shù)據(jù)庫(kù)中，卻不能有同名的Check約束。所以，建議使用 ck_ + 表名 + 字段名 來(lái)命名它，比如這個(gè)范例腳本中的 ck_ArticleType。

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

主鍵的命名

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

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

可見(jiàn)，對(duì)于主鍵pk_StudentCourse，包含了兩個(gè)字段StudentId 和 CourseId。

外鍵的命名

外鍵的命名為 fk_外鍵所在的表名_外鍵引用的表名 。因?yàn)橥怄I所在的表為從表，所以上式可以寫(xiě)為 fk_從表名_主表名 。

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

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

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

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

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

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

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

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

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

觸發(fā)器的命名

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

1. 前綴(tr),描述了數(shù)據(jù)庫(kù)對(duì)象的類(lèi)型。
2. 基本部分，描述觸發(fā)器所加的表。
3. 后綴(_I、_U、_D)，顯示了修改語(yǔ)句(Insert, Update及Delete)

存儲(chǔ)過(guò)程的命名

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

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

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

1. 動(dòng)詞放前面，名詞放后面。
2. 名詞放前面，動(dòng)詞放后面。

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

以NorthWind 為例，假如對(duì)于 Employees 表你有4個(gè)存儲(chǔ)過(guò)程，分別命名為：prEmployeeInsert、prEmployeeUpdate、prEmployeeDelById、prEmployeeGetById

同時(shí)對(duì)于 Products 表你有類(lèi)似的4個(gè)存儲(chǔ)過(guò)程，分別命名為：prProductInsert、prProductUpdate、prProductDelById、prProductGetById

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

prEmployeeDelById
prEmployeeGetById
prEmployeeInsert
prEmployeeUpdate
prProductDelById
prProductGetById
prProductInsert
prProductUpdate

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

存儲(chǔ)過(guò)程中參數(shù)的命名

存儲(chǔ)過(guò)程中的入口參數(shù)，我建議與其對(duì)應(yīng)的字段名相同，這里，假設(shè)要寫(xiě)一個(gè)更新Northwind數(shù)據(jù)庫(kù)Employees表的存儲(chǔ)過(guò)程(做了簡(jiǎn)化)，可以這么寫(xiě)：

    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 ‘更新用戶(hù)失敗’
  

總結(jié)

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

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

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

SQL數(shù)據(jù)庫(kù)設(shè)計(jì)規(guī)范參考之?dāng)?shù)據(jù)庫(kù)對(duì)象命名詳細(xì)文檔