一戈鲁、什么是主鍵、外鍵：

關(guān)系型數(shù)據(jù)庫中的一條記錄中有若干個(gè)屬性嘹叫，若其中某一個(gè)屬性組(注意是組)能唯一標(biāo)識(shí)一條記錄婆殿，該屬性組就可以成為一個(gè)主鍵 ，比如? ：

學(xué)生表(學(xué)號(hào)罩扇，姓名婆芦，性別，班級(jí))?????其中每個(gè)學(xué)生的學(xué)號(hào)是唯一的喂饥，學(xué)號(hào)就是一個(gè)主鍵寞缝。

課程表(課程編號(hào),課程名,學(xué)分)?????其中課程編號(hào)是唯一的,課程編號(hào)就是一個(gè)主鍵 。

成績表(學(xué)號(hào),課程號(hào),成績)?????成績表中單一 一個(gè)屬性無法唯一標(biāo)識(shí)一條記錄仰泻，學(xué)號(hào)和課程號(hào)的組合才可以唯一標(biāo)識(shí)一條記錄，所以學(xué)號(hào)和課程號(hào)的屬性組合是一個(gè)主鍵 (聯(lián)合主鍵)

成績表中的學(xué)號(hào)不是成績表的主鍵滩届，但它和學(xué)生表中的學(xué)號(hào)相對(duì)應(yīng)集侯，并且學(xué)生表中的學(xué)號(hào)是學(xué)生表的主鍵，因而稱成績表中的學(xué)號(hào)是學(xué)生表的外鍵帜消。 ? 同理棠枉，成績表中的課程號(hào)是課程表的外鍵。 ? 定義主鍵和外鍵主要是為了維護(hù)關(guān)系數(shù)據(jù)庫的完整性泡挺。

總結(jié)一下：

1.主鍵是能確定一條記錄的唯一標(biāo)識(shí)辈讶，比如，一條記錄包括身份正號(hào)娄猫，姓名贱除，年齡。

身份證號(hào)是唯一能確定這個(gè)人的媳溺，其他都可能有重復(fù)月幌，所以，身份證號(hào)是主鍵悬蔽。

?2.外鍵用于與另一張表的關(guān)聯(lián)扯躺。是能確定另一張表記錄的字段，用于保持?jǐn)?shù)據(jù)的一致性蝎困。

比如录语，A表中的一個(gè)字段xooc，是B表的主鍵禾乘，那這個(gè)字段xooc就可以是A表的外鍵澎埠。

二、?主鍵盖袭、外鍵和索引的區(qū)別?

主鍵失暂、外鍵和索引的區(qū)別》》》

主鍵：

????定義：唯一標(biāo)識(shí)一條記錄彼宠，不能有重復(fù)的，不允許為空弟塞；

????個(gè)數(shù)：主鍵只能有一個(gè)凭峡；

作用：用來保證數(shù)據(jù)完整性；

外鍵：

? ? 定義：表的外鍵是另一表的主鍵,?外鍵可以有重復(fù)的,?可以是空值决记；

????個(gè)數(shù)：一個(gè)表可以有多個(gè)外鍵摧冀；

????作用：用來和其他表建立聯(lián)系用的；

索引：

????定義：該字段沒有重復(fù)值系宫，但可以有一個(gè)空值

????個(gè)數(shù)：一個(gè)表可以有多個(gè)惟一索引

????作用：用于提高查詢排序的速度

聚集索引和非聚集索引的區(qū)別》》》

????聚集索引一定是唯一索引索昂。但唯一索引不一定是聚集索引。??

????聚集索引扩借，在索引頁里直接存放數(shù)據(jù)椒惨，而非聚集索引在索引頁里存放的是索引，這些索引指向?qū)ｉT的數(shù)據(jù)頁的數(shù)據(jù)潮罪。

三康谆、數(shù)據(jù)庫中主鍵和外鍵的設(shè)計(jì)原則

????主鍵和外鍵是把多個(gè)表組織為一個(gè)有效的關(guān)系數(shù)據(jù)庫的粘合劑。主鍵和外鍵的設(shè)計(jì)對(duì)物理數(shù)據(jù)庫的性能和可用性都有著決定性的影響嫉到。

????必須將數(shù)據(jù)庫模式從理論上的邏輯設(shè)計(jì)轉(zhuǎn)換為實(shí)際的物理設(shè)計(jì)沃暗。而主鍵和外鍵的結(jié)構(gòu)是這個(gè)設(shè)計(jì)過程的癥結(jié)所在。一旦將所設(shè)計(jì)的數(shù)據(jù)庫用于了生產(chǎn)環(huán)境何恶，就很難對(duì)這些鍵進(jìn)行修改孽锥，所以在開發(fā)階段就設(shè)計(jì)好主鍵和外鍵就是非常必要和值得的。

主鍵：

關(guān)系數(shù)據(jù)庫依賴于主鍵---它是數(shù)據(jù)庫物理模式的基石细层。

??主鍵在物理層面上只有兩個(gè)用途：

1.惟一地標(biāo)識(shí)一行惜辑。

2.作為一個(gè)可以被外鍵有效引用的對(duì)象。

??基于以上這兩個(gè)用途疫赎，下面給出了我在設(shè)計(jì)物理層面的主鍵時(shí)所遵循的一些原則：

1.主鍵應(yīng)當(dāng)是對(duì)用戶沒有意義的韵丑。如果用戶看到了一個(gè)表示多對(duì)多關(guān)系的連接表中的數(shù)據(jù)，并抱怨它沒有什么用處虚缎，那就證明它的主鍵設(shè)計(jì)地很好撵彻。

2.主鍵應(yīng)該是單列的，以便提高連接和篩選操作的效率实牡。

???????注：使用復(fù)合鍵的人通常有兩個(gè)理由為自己開脫陌僵，而這兩個(gè)理由都是錯(cuò)誤的。

其一是主鍵應(yīng)當(dāng)具有實(shí)際意義创坞，然而碗短，讓主鍵具有意義只不過是給人為地破壞數(shù)據(jù)庫提供了方便。其二是利用這種方法可以在描述多對(duì)多關(guān)系的連接表中使用兩個(gè)外部鍵來作為主鍵题涨，我也反對(duì)這種做法偎谁，理由是：復(fù)合主鍵常常導(dǎo)致不良的外鍵总滩，即當(dāng)連接表成為另一個(gè)從表的主表，而依據(jù)上面的第二種方法成為這個(gè)表主鍵的一部分巡雨，然闰渔，這個(gè)表又有可能再成為其它從表的主表，其主鍵又有可能成了其它從表主鍵的一部分铐望，如此傳遞下去冈涧，越靠后的從表，其主鍵將會(huì)包含越多的列了正蛙。

3.永遠(yuǎn)也不要更新主鍵督弓。實(shí)際上，因?yàn)橹麈I除了惟一地標(biāo)識(shí)一行之外乒验，再?zèng)]有其他的用途了愚隧，所以也就沒有理由去對(duì)它更新。如果主鍵需要更新锻全，則說明主鍵應(yīng)對(duì)用戶無意義的原則被違反了奸攻。

???????注：這項(xiàng)原則對(duì)于那些經(jīng)常需要在數(shù)據(jù)轉(zhuǎn)換或多數(shù)據(jù)庫合并時(shí)進(jìn)行數(shù)據(jù)整理的數(shù)據(jù)并不適用。

4.主鍵不應(yīng)包含動(dòng)態(tài)變化的數(shù)據(jù)虱痕，如時(shí)間戳、創(chuàng)建時(shí)間列辐赞、修改時(shí)間列等部翘。

5.主鍵應(yīng)當(dāng)有計(jì)算機(jī)自動(dòng)生成。如果由人來對(duì)主鍵的創(chuàng)建進(jìn)行干預(yù)响委，就會(huì)使它帶有除了惟一標(biāo)識(shí)一行以外的意義新思。一旦越過這個(gè)界限，就可能產(chǎn)生認(rèn)為修改主鍵的動(dòng)機(jī)赘风，這樣夹囚，這種系統(tǒng)用來鏈接記錄行、管理記錄行的關(guān)鍵手段就會(huì)落入不了解數(shù)據(jù)庫設(shè)計(jì)的人的手中邀窃。

四荸哟、數(shù)據(jù)庫主鍵選取策略

????我們?cè)诮?shù)據(jù)庫的時(shí)候，需要為每張表指定一個(gè)主鍵瞬捕，所謂主鍵就是能夠唯一標(biāo)識(shí)表中某一行的屬性或?qū)傩越M鞍历，一個(gè)表只能有一個(gè)主鍵，但可以有多個(gè)候選索引肪虎。因?yàn)橹麈I可以唯一標(biāo)識(shí)某一行記錄劣砍，所以可以確保執(zhí)行數(shù)據(jù)更新、刪除的時(shí)候不會(huì)出現(xiàn)張冠李戴的錯(cuò)誤扇救。當(dāng)然刑枝，其它字段可以輔助我們?cè)趫?zhí)行這些操作時(shí)消除共享沖突香嗓，不過就不在這里討論了。主鍵除了上述作用外装畅，常常與外鍵構(gòu)成參照完整性約束靠娱，防止出現(xiàn)數(shù)據(jù)不一致。所以數(shù)據(jù)庫在設(shè)計(jì)時(shí)洁灵，主鍵起到了很重要的作用饱岸。

常見的數(shù)據(jù)庫主鍵選取方式有：

·?自動(dòng)增長字段

·?手動(dòng)增長字段

·?UniqueIdentifier

·?“COMB（Combine）”類型

1自動(dòng)增長型字段

很多數(shù)據(jù)庫設(shè)計(jì)者喜歡使用自動(dòng)增長型字段，因?yàn)樗褂煤唵位涨АＷ詣?dòng)增長型字段允許我們?cè)谙驍?shù)據(jù)庫添加數(shù)據(jù)時(shí)苫费，不考慮主鍵的取值，記錄插入后双抽，數(shù)據(jù)庫系統(tǒng)會(huì)自動(dòng)為其分配一個(gè)值百框，確保絕對(duì)不會(huì)出現(xiàn)重復(fù)。如果使用SQL?Server數(shù)據(jù)庫的話牍汹，我們還可以在記錄插入后使用@@IDENTITY全局變量獲取系統(tǒng)分配的主鍵鍵值铐维。

盡管自動(dòng)增長型字段會(huì)省掉我們很多繁瑣的工作，但使用它也存在潛在的問題慎菲，那就是在數(shù)據(jù)緩沖模式下嫁蛇，很難預(yù)先填寫主鍵與外鍵的值。假設(shè)有兩張表：

Order(OrderID,?OrderDate)

OrderDetial(OrderID,?LineNum,?ProductID,?Price)

Order表中的OrderID是自動(dòng)增長型的字段÷陡茫現(xiàn)在需要我們錄入一張訂單睬棚，包括在Order表中插入一條記錄以及在OrderDetail表中插入若干條記錄。因?yàn)镺rder表中的OrderID是自動(dòng)增長型的字段解幼，那么我們?cè)谟涗浾讲迦氲綌?shù)據(jù)庫之前無法事先得知它的取值抑党，只有在更新后才能知道數(shù)據(jù)庫為它分配的是什么值。這會(huì)造成以下矛盾發(fā)生：

首先撵摆，為了能在OrderDetail的OrderID字段中添入正確的值底靠，必須先更新Order表以獲取到系統(tǒng)為其分配的OrderID值，然后再用這個(gè)OrderID填充OrderDetail表特铝。最后更新OderDetail表暑中。但是，為了確保數(shù)據(jù)的一致性鲫剿，Order與OrderDetail在更新時(shí)必須在事務(wù)保護(hù)下同時(shí)進(jìn)行痒芝，即確保兩表同時(shí)更行成功。顯然它們是相互矛盾的牵素。

除此之外严衬，當(dāng)我們需要在多個(gè)數(shù)據(jù)庫間進(jìn)行數(shù)據(jù)的復(fù)制時(shí)（SQL?Server的數(shù)據(jù)分發(fā)、訂閱機(jī)制允許我們進(jìn)行庫間的數(shù)據(jù)復(fù)制操作）笆呆，自動(dòng)增長型字段可能造成數(shù)據(jù)合并時(shí)的主鍵沖突请琳。設(shè)想一個(gè)數(shù)據(jù)庫中的Order表向另一個(gè)庫中的Order表復(fù)制數(shù)據(jù)庫時(shí)粱挡，OrderID到底該不該自動(dòng)增長呢？

ADO.NET允許我們?cè)贒ataSet中將某一個(gè)字段設(shè)置為自動(dòng)增長型字段俄精，但千萬記住询筏，這個(gè)自動(dòng)增長字段僅僅是個(gè)占位符而已，當(dāng)數(shù)據(jù)庫進(jìn)行更新時(shí)竖慧，數(shù)據(jù)庫生成的值會(huì)自動(dòng)取代ADO.Net分配的值嫌套。所以為了防止用戶產(chǎn)生誤解，建議大家將ADO.NET中的自動(dòng)增長初始值以及增量都設(shè)置成-1圾旨。此外踱讨，在ADO.NET中，我們可以為兩張表建立DataRelation砍的，這樣存在級(jí)聯(lián)關(guān)系的兩張表更新時(shí)痹筛，一張表更新后另外一張表對(duì)應(yīng)鍵的值也會(huì)自動(dòng)發(fā)生變化，這會(huì)大大減少了我們對(duì)存在級(jí)聯(lián)關(guān)系的兩表間更新時(shí)自動(dòng)增長型字段帶來的麻煩廓鞠。

2手動(dòng)增長型字段

既然自動(dòng)增長型字段會(huì)帶來如此的麻煩帚稠，我們不妨考慮使用手動(dòng)增長型的字段，也就是說主鍵的值需要自己維護(hù)床佳，通常情況下需要建立一張單獨(dú)的表存儲(chǔ)當(dāng)前主鍵鍵值滋早。還用上面的例子來說，這次我們新建一張表叫IntKey砌们，包含兩個(gè)字段杆麸，KeyName以及KeyValue。就像一個(gè)HashTable怨绣，給一個(gè)KeyName，就可以知道目前的KeyValue是什么拷获，然后手工實(shí)現(xiàn)鍵值數(shù)據(jù)遞增篮撑。在SQL?Server中可以編寫這樣一個(gè)存儲(chǔ)過程，讓取鍵值的過程自動(dòng)進(jìn)行匆瓜。代碼如下：

CREATE?PROCEDURE?[GetKey]@KeyName?char(10),?@KeyValue?int?OUTPUT?ASUPDATE?IntKey?SET?@KeyValue?=?KeyValue?=?KeyValue?+?1?WHERE?KeyName?=?@KeyNameGo

這樣赢笨，通過調(diào)用存儲(chǔ)過程，我們可以獲得最新鍵值驮吱，確保不會(huì)出現(xiàn)重復(fù)茧妒。若將OrderID字段設(shè)置為手動(dòng)增長型字段，我們的程序可以由以下幾步來實(shí)現(xiàn)：首先調(diào)用存儲(chǔ)過程左冬，獲得一個(gè)OrderID桐筏，然后使用這個(gè)OrderID填充Order表與OrderDetail表，最后在事務(wù)保護(hù)下對(duì)兩表進(jìn)行更新拇砰。

使用手動(dòng)增長型字段作為主鍵在進(jìn)行數(shù)據(jù)庫間數(shù)據(jù)復(fù)制時(shí)梅忌，可以確保數(shù)據(jù)合并過程中不會(huì)出現(xiàn)鍵值沖突狰腌，只要我們?yōu)椴煌臄?shù)據(jù)庫分配不同的主鍵取值段就行了。但是牧氮，使用手動(dòng)增長型字段會(huì)增加網(wǎng)絡(luò)的RoundTrip琼腔，我們必須通過增加一次數(shù)據(jù)庫訪問來獲取當(dāng)前主鍵鍵值，這會(huì)增加網(wǎng)絡(luò)和數(shù)據(jù)庫的負(fù)載踱葛，當(dāng)處于一個(gè)低速或斷開的網(wǎng)絡(luò)環(huán)境中時(shí)丹莲，這種做法會(huì)有很大的弊端。同時(shí)尸诽，手工維護(hù)主鍵還要考慮并發(fā)沖突等種種因素甥材，這更會(huì)增加系統(tǒng)的復(fù)雜程度。

3使用UniqueIdentifier

SQL?Server為我們提供了UniqueIdentifier數(shù)據(jù)類型逊谋，并提供了一個(gè)生成函數(shù)NEWID(?)擂达，使用NEWID(?)可以生成一個(gè)唯一的UniqueIdentifier。UniqueIdentifier在數(shù)據(jù)庫中占用16個(gè)字節(jié)胶滋，出現(xiàn)重復(fù)的概率非常小板鬓，以至于可以認(rèn)為是0。我們經(jīng)常從注冊(cè)表中看到類似

{45F0EB02-0727-4F2E-AAB5-E8AEDEE0CEC5}

的東西實(shí)際上就是一個(gè)UniqueIdentifier究恤，Windows用它來做COM組件以及接口的標(biāo)識(shí)俭令，防止出現(xiàn)重復(fù)。在.NET里管UniqueIdentifier稱之為GUID（Global?Unique?Identifier）部宿。在C#中可以使用如下命令生成一個(gè)GUID：

Guid?u?=?System.Guid.NewGuid();

對(duì)于上面提到的Order與OrderDetail的程序抄腔，如果選用UniqueIdentifier作為主鍵的話，我們完全可以避免上面提到的增加網(wǎng)絡(luò)RoundTrip的問題理张。通過程序直接生成GUID填充主鍵赫蛇，不用考慮是否會(huì)出現(xiàn)重復(fù)。

UniqueIdentifier字段也存在嚴(yán)重的缺陷：首先雾叭，它的長度是16字節(jié)悟耘，是整數(shù)的4倍長，會(huì)占用大量存儲(chǔ)空間织狐。更為嚴(yán)重的是暂幼，UniqueIdentifier的生成毫無規(guī)律可言，要想在上面建立索引（絕大多數(shù)數(shù)據(jù)庫在主鍵上都有索引）是一個(gè)非常耗時(shí)的操作移迫。有人做過實(shí)驗(yàn)旺嬉，插入同樣的數(shù)據(jù)量，使用UniqueIdentifier型數(shù)據(jù)做主鍵要比使用Integer型數(shù)據(jù)慢厨埋，所以邪媳，出于效率考慮，盡可能避免使用UniqueIdentifier型數(shù)據(jù)庫作為主鍵鍵值。

4使用“COMB（Combine）”類型

既然上面三種主鍵類型選取策略都存在各自的缺點(diǎn)悲酷，那么到底有沒有好的辦法加以解決呢套菜？答案是肯定的。通過使用COMB類型（數(shù)據(jù)庫中沒有COMB類型设易，它是Jimmy?Nilsson在他的“The?Cost?of?GUIDs?as?Primary?Keys”一文中設(shè)計(jì)出來的）逗柴，可以在三者之間找到一個(gè)很好的平衡點(diǎn)。

COMB數(shù)據(jù)類型的基本設(shè)計(jì)思路是這樣的：既然UniqueIdentifier數(shù)據(jù)因毫無規(guī)律可言造成索引效率低下顿肺，影響了系統(tǒng)的性能戏溺，那么我們能不能通過組合的方式，保留UniqueIdentifier的前10個(gè)字節(jié)屠尊，用后6個(gè)字節(jié)表示GUID生成的時(shí)間（DateTime）旷祸，這樣我們將時(shí)間信息與UniqueIdentifier組合起來，在保留UniqueIdentifier的唯一性的同時(shí)增加了有序性讼昆，以此來提高索引效率托享。也許有人會(huì)擔(dān)心UniqueIdentifier減少到10字節(jié)會(huì)造成數(shù)據(jù)出現(xiàn)重復(fù)，其實(shí)不用擔(dān)心浸赫，后6字節(jié)的時(shí)間精度可以達(dá)到1/300秒闰围，兩個(gè)COMB類型數(shù)據(jù)完全相同的可能性是在這1/300秒內(nèi)生成的兩個(gè)GUID前10個(gè)字節(jié)完全相同，這幾乎是不可能的既峡！在SQL?Server中用SQL命令將這一思路實(shí)現(xiàn)出來便是：

DECLARE?@aGuid?UNIQUEIDENTIFIERSET?@aGuid?=?CAST(CAST(NEWID()?AS?BINARY(10))?+?CAST(GETDATE()?AS?BINARY(6))?AS?UNIQUEIDENTIFIER)

經(jīng)過測試羡榴，使用COMB做主鍵比使用INT做主鍵，在檢索运敢、插入校仑、更新、刪除等操作上仍然顯慢传惠，但比Unidentifier類型要快上一些迄沫。關(guān)于測試數(shù)據(jù)可以

========================? 以下是僅供參考的代碼================》》》

除了使用存儲(chǔ)過程實(shí)現(xiàn)COMB數(shù)據(jù)外，我們也可以使用C#生成COMB數(shù)據(jù)卦方，這樣所有主鍵生成工作可以在客戶端完成羊瘩。C#代碼如下：

//================

///<summary>

///返回?GUID?用于數(shù)據(jù)庫操作，特定的時(shí)間代碼可以提高檢索效率

///</summary>

///<returns>COMB?(GUID與時(shí)間混合型)?類型?GUID?數(shù)據(jù)</returns>public?static?Guid?NewComb()?{??????byte[]?guidArray?=?System.Guid.NewGuid().ToByteArray();??????DateTime?baseDate?=?new?DateTime(1900,1,1);??????DateTime?now?=?DateTime.Now;??????//?Get?the?days?and?milliseconds?which?will?be?used?to?build?the?byte?string

?????TimeSpan?days?=?new?TimeSpan(now.Ticks?-?baseDate.Ticks);??????TimeSpan?msecs?=?new?TimeSpan(now.Ticks?-?(new?DateTime(now.Year,?now.Month,?now.Day).Ticks));??????//?Convert?to?a?byte?array

//?Note?that?SQL?Server?is?accurate?to?1/300th?of?a?millisecond?so?we?divide?by?3.333333

?????byte[]?daysArray?=?BitConverter.GetBytes(days.Days);??????byte[]?msecsArray?=?BitConverter.GetBytes((long)(msecs.TotalMilliseconds/3.333333));??????//?Reverse?the?bytes?to?match?SQL?Servers?ordering

?????Array.Reverse(daysArray);??????Array.Reverse(msecsArray);??????//?Copy?the?bytes?into?the?guid

?????Array.Copy(daysArray,?daysArray.Length?-?2,?guidArray,?guidArray.Length?-?6,?2);??????Array.Copy(msecsArray,?msecsArray.Length?-?4,?guidArray,?guidArray.Length?-?4,?4);??????return?new?System.Guid(guidArray);?}?//===================

///<summary>

///從?SQL?SERVER?返回的?GUID?中生成時(shí)間信息

///</summary>

///<param?name="guid">包含時(shí)間信息的?COMB?</param>

///<returns>時(shí)間</returns>public?static?DateTime?GetDateFromComb(System.Guid?guid)?{??????DateTime?baseDate?=?new?DateTime(1900,1,1);??????byte[]?daysArray?=?new?byte[4];??????byte[]?msecsArray?=?new?byte[4];??????byte[]?guidArray?=?guid.ToByteArray();??????//?Copy?the?date?parts?of?the?guid?to?the?respective?byte?arrays.

?????Array.Copy(guidArray,?guidArray.Length?-?6,?daysArray,?2,?2);??????Array.Copy(guidArray,?guidArray.Length?-?4,?msecsArray,?0,?4);??????//?Reverse?the?arrays?to?put?them?into?the?appropriate?order

?????Array.Reverse(daysArray);??????Array.Reverse(msecsArray);??????//?Convert?the?bytes?to?ints

?????int?days?=?BitConverter.ToInt32(daysArray,?0);??????int?msecs?=?BitConverter.ToInt32(msecsArray,?0);??????DateTime?date?=?baseDate.AddDays(days);??????date?=?date.AddMilliseconds(msecs?*?3.333333);??????return?date;?

}?