一、什么是主鍵、外鍵
- 表1屬性有：typeid（主鍵），type
- 表2屬性有：goodid（主鍵），typeid（外鍵，引用表1中的typeid）
問題1：以上哪一個是外鍵表，哪一個是主鍵表?
- 表1是主鍵表
- 表1的主鍵字段在表2中做外鍵、而表1自己卻沒有外鍵
- 表2是外鍵表
- 有一個依賴表1的typeid的字段、作為外鍵、取值必須是其依賴主鍵表表1中主鍵字段有的值
問題2：同一個表的主鍵可以是外鍵嗎，注意，我說的是同一個表？
- 比如表A（a_ID）表B(b_ID)，設置表A的a_ID作為主鍵，同時設置為外鍵與表B(b_ID)關聯。
當然可以
二、主鍵、外鍵和索引的區別
一個關系表事實上是具有共同屬性的一類實體的集合。按照集合的定義，集合中元素不能重復。同樣，關系表中也不應該有重復記錄。例如在學生表中，存有兩條一樣的學生記錄是不必要的，也是不合適的。
在現實世界中，除了事物本身的信息外，事物之間還存在着很多聯系，這種聯系反映到數據庫中就體現為表之間的聯系。例如在圖1中，學生表存儲學生信息，系表存儲系的信息。但學生表和系表之間是有聯系的：每個學生都屬於一個系，而每個系都可以包含多名學生，所以學生表和系表就存在着“屬於”的聯系。
圖1
在關系數據庫中，如何存儲這種聯系的信息呢？就要借助“外鍵”實現。如果一個表中的某一列是另外一個表的中的主鍵，那么稱這列為外鍵。例如圖1學生表中“系號”就是外鍵，因為系號是系表的主鍵（建立主外鍵關系的前提是兩張表中有相同的字段和屬性）。在學生表中設計了“系號”一列，就是為了存儲學生和系之間的聯系信息。
外鍵就是連接兩個表的紐帶。通過外鍵和主鍵的等值連接，如圖1，就可以將不同表里的相關紀錄連接在一起，從而實現了數據庫中相關數據的查找。利用外鍵，可以查詢每個學生所在系的信息，也可以查詢在制定的系所包含的學生信息。
當兩個表通過“外鍵－主鍵”建立了聯系之后，就要保持兩表數據的一致性。例如在插入學生記錄的同時，外鍵的值（系號）必須是系表中主鍵的有效值（必須有這個系），或者是空值（學生的系暫未確定）；又如，在刪除系表記錄時，如果在學生表里還有該系學生的記錄（該系還有學生在就讀），那么系記錄就不能刪除。
下面再分析一個員工信息管理系統的例子。該數據庫中建有員工基本信息表（person）、部門編碼表（deparment）和學歷編碼表（education），如圖2所示：
圖2
部門編碼表保存了部門編號和部門名稱，部門編號（DepID）是主鍵，每個部門的編號在表中具有唯一性，這樣就能保證每行都可以用主鍵來標識。
學歷編碼表保存了學歷編號和學歷名稱，學歷編號（EduID）是主鍵。
員工基本信息表存儲員工的基本信息，需要包括工作證號、姓名、部門編號、職務、工資、學歷編號等字段，工作證號（ID）是該表的主鍵。在該表中，Department列是一個外鍵，匹配部門編碼表中的DepID主鍵；Education列也是一個外鍵，匹配學歷編碼表中的EduID主鍵。利用外鍵和主鍵的連接，就可以查詢出某人，如張三的部門是經理室，他的學歷室碩士。
利用“外鍵－主鍵”的連接方式能更好奪得簡化數據庫設計過程，減少數據冗余，提高數據庫效率。
三、數據庫中主鍵和外鍵的設計原則
主鍵和外鍵是把多個表組織為一個有效的關系數據庫的粘合劑。主鍵和外鍵的設計對物理數據庫的性能和可用性都有着決定性的影響。
必須將數據庫模式從理論上的邏輯設計轉換為實際的物理設計。而主鍵和外鍵的結構是這個設計過程的症結所在。一旦將所設計的數據庫用於了生產環境，就很難對這些鍵進行修改，所以在開發階段就設計好主鍵和外鍵就是非常必要和值得的。
主鍵：
關系數據庫依賴於主鍵---它是數據庫物理模式的基石。
主鍵在物理層面上只有兩個用途：
1. 惟一地標識一行。
2. 作為一個可以被外鍵有效引用的對象。
基於以上這兩個用途，下面給出了我在設計物理層面的主鍵時所遵循的一些原則：
1. 主鍵應當是對用戶沒有意義的。如果用戶看到了一個表示多對多關系的連接表中的數據，並抱怨它沒有什么用處，那就證明它的主鍵設計地很好。
2. 主鍵應該是單列的，以便提高連接和篩選操作的效率。
注：使用復合鍵的人通常有兩個理由為自己開脫，而這兩個理由都是錯誤的。其一是主鍵應當具有實際意義，然而，讓主鍵具有意義只不過是給人為地破壞數據庫提供了方便。其二是利用這種方法可以在描述多對多關系的連接表中使用兩個外部鍵來作為主鍵，我也反對這種做法，理由是：復合主鍵常常導致不良的外鍵，即當連接表成為另一個從表的主表，而依據上面的第二種方法成為這個表主鍵的一部分，然，這個表又有可能再成為其它從表的主表，其主鍵又有可能成了其它從表主鍵的一部分，如此傳遞下去，越靠后的從表，其主鍵將會包含越多的列了。
3. 永遠也不要更新主鍵。實際上，因為主鍵除了惟一地標識一行之外，再沒有其他的用途了，所以也就沒有理由去對它更新。如果主鍵需要更新，則說明主鍵應對用戶無意義的原則被違反了。
注：這項原則對於那些經常需要在數據轉換或多數據庫合並時進行數據整理的數據並不適用。
4. 主鍵不應包含動態變化的數據，如時間戳、創建時間列、修改時間列等。
5. 主鍵應當有計算機自動生成。如果由人來對主鍵的創建進行干預，就會使它帶有除了惟一標識一行以外的意義。一旦越過這個界限，就可能產生認為修改主鍵的動機，這樣，這種系統用來鏈接記錄行、管理記錄行的關鍵手段就會落入不了解數據庫設計的人的手中。
四、數據庫主鍵選取策略
我們在建立數據庫的時候，需要為每張表指定一個主鍵，所謂主鍵就是能夠唯一標識表中某一行的屬性或屬性組，一個表只能有一個主鍵，但可以有多個候選索引。因為主鍵可以唯一標識某一行記錄，所以可以確保執行數據更新、刪除的時候不會出現張冠李戴的錯誤。當然，其它字段可以輔助我們在執行這些操作時消除共享沖突，不過就不在這里討論了。主鍵除了上述作用外，常常與外鍵構成參照完整性約束，防止出現數據不一致。所以數據庫在設計時，主鍵起到了很重要的作用。
常見的數據庫主鍵選取方式有：
· 自動增長字段
· 手動增長字段
· UniqueIdentifier
· "COMB(Combine)"類型
1.自動增長型字段
很多數據庫設計者喜歡使用自動增長型字段，因為它使用簡單。自動增長型字段允許我們在向數據庫添加數據時，不考慮主鍵的取值，記錄插入后，數據庫系統會自動為其分配一個值，確保絕對不會出現重復。如果使用SQL Server數據庫的話，我們還可以在記錄插入后使用@@IDENTITY全局變量獲取系統分配的主鍵鍵值。
盡管自動增長型字段會省掉我們很多繁瑣的工作，但使用它也存在潛在的問題，那就是在數據緩沖模式下，很難預先填寫主鍵與外鍵的值。假設有兩張表：
Order(OrderID, OrderDate)
OrderDetial(OrderID, LineNum, ProductID, Price)
Order表中的OrderID是自動增長型的字段。現在需要我們錄入一張訂單，包括在Order表中插入一條記錄以及在OrderDetail表中插入若干條記錄。因為Order表中的OrderID是自動增長型的字段，那么我們在記錄正式插入到數據庫之前無法事先得知它的取值，只有在更新后才能知道數據庫為它分配的是什么值。這會造成以下矛盾發生：
首先，為了能在OrderDetail的OrderID字段中添入正確的值，必須先更新Order表以獲取到系統為其分配的OrderID值，然后再用這個OrderID填充OrderDetail表。最后更新OderDetail表。但是，為了確保數據的一致性，Order與OrderDetail在更新時必須在事務保護下同時進行，即確保兩表同時更行成功。顯然它們是相互矛盾的。
除此之外，當我們需要在多個數據庫間進行數據的復制時（SQL Server的數據分發、訂閱機制允許我們進行庫間的數據復制操作），自動增長型字段可能造成數據合並時的主鍵沖突。設想一個數據庫中的Order表向另一個庫中的Order表復制數據庫時，OrderID到底該不該自動增長呢？
ADO.NET允許我們在DataSet中將某一個字段設置為自動增長型字段，但千萬記住，這個自動增長字段僅僅是個占位符而已，當數據庫進行更新時，數據庫生成的值會自動取代ADO.Net分配的值。所以為了防止用戶產生誤解，建議大家將ADO.NET中的自動增長初始值以及增量都設置成-1。此外，在ADO.NET中，我們可以為兩張表建立DataRelation，這樣存在級聯關系的兩張表更新時，一張表更新后另外一張表對應鍵的值也會自動發生變化，這會大大減少了我們對存在級聯關系的兩表間更新時自動增長型字段帶來的麻煩。
2.手動增長型字段
既然自動增長型字段會帶來如此的麻煩，我們不妨考慮使用手動增長型的字段，也就是說主鍵的值需要自己維護，通常情況下需要建立一張單獨的表存儲當前主鍵鍵值。還用上面的例子來說，這次我們新建一張表叫IntKey，包含兩個字段，KeyName以及KeyValue。就像一個HashTable，給一個KeyName，就可以知道目前的KeyValue是什么，然后手工實現鍵值數據遞增。在SQL Server中可以編寫這樣一個存儲過程，讓取鍵值的過程自動進行。代碼如下：
CREATE PROCEDURE [GetKey] @KeyName char(10), @KeyValue int OUTPUT AS UPDATE IntKey SET @KeyValue = KeyValue = KeyValue + 1 WHERE KeyName = @KeyName Go
這樣，通過調用存儲過程，我們可以獲得最新鍵值，確保不會出現重復。若將OrderID字段設置為手動增長型字段，我們的程序可以由以下幾步來實現：首先調用存儲過程，獲得一個OrderID，然后使用這個OrderID填充Order表與OrderDetail表，最后在事務保護下對兩表進行更新。
使用手動增長型字段作為主鍵在進行數據庫間數據復制時，可以確保數據合並過程中不會出現鍵值沖突，只要我們為不同的數據庫分配不同的主鍵取值段就行了。但是，使用手動增長型字段會增加網絡的RoundTrip，我們必須通過增加一次數據庫訪問來獲取當前主鍵鍵值，這會增加網絡和數據庫的負載，當處於一個低速或斷開的網絡環境中時，這種做法會有很大的弊端。同時，手工維護主鍵還要考慮並發沖突等種種因素，這更會增加系統的復雜程度。
3.使用UniqueIdentifier
SQL Server為我們提供了UniqueIdentifier數據類型，並提供了一個生成函數NEWID( )，使用NEWID( )可以生成一個唯一的UniqueIdentifier。UniqueIdentifier在數據庫中占用16個字節，出現重復的概率非常小，以至於可以認為是0。我們經常從注冊表中看到類似
{45F0EB02-0727-4F2E-AAB5-E8AEDEE0CEC5}的東西實際上就是一個UniqueIdentifier，Windows用它來做COM組件以及接口的標識，防止出現重復。在.NET里管UniqueIdentifier稱之為GUID（Global Unique Identifier）。在C#中可以使用如下命令生成一個GUID：
Guid u = System.Guid.NewGuid()
對於上面提到的Order與OrderDetail的程序，如果選用UniqueIdentifier作為主鍵的話，我們完全可以避免上面提到的增加網絡RoundTrip的問題。通過程序直接生成GUID填充主鍵，不用考慮是否會出現重復。
UniqueIdentifier字段也存在嚴重的缺陷：首先，它的長度是16字節，是整數的4倍長，會占用大量存儲空間。更為嚴重的是，UniqueIdentifier的生成毫無規律可言，要想在上面建立索引（絕大多數數據庫在主鍵上都有索引）是一個非常耗時的操作。有人做過實驗，插入同樣的數據量，使用UniqueIdentifier型數據做主鍵要比使用Integer型數據慢，所以，出於效率考慮，盡可能避免使用UniqueIdentifier型數據庫作為主鍵鍵值。
4.使用“COMB（Combine）”類型
既然上面三種主鍵類型選取策略都存在各自的缺點，那么到底有沒有好的辦法加以解決呢？答案是肯定的。通過使用COMB類型（數據庫中沒有COMB類型，它是Jimmy Nilsson在他的“The Cost of GUIDs as Primary Keys”一文中設計出來的），可以在三者之間找到一個很好的平衡點。
COMB數據類型的基本設計思路是這樣的：既然UniqueIdentifier數據因毫無規律可言造成索引效率低下，影響了系統的性能，那么我們能不能通過組合的方式，保留UniqueIdentifier的前10個字節，用后6個字節表示GUID生成的時間（DateTime），這樣我們將時間信息與UniqueIdentifier組合起來，在保留UniqueIdentifier的唯一性的同時增加了有序性，以此來提高索引效率。也許有人會擔心UniqueIdentifier減少到10字節會造成數據出現重復，其實不用擔心，后6字節的時間精度可以達到1/300秒，兩個COMB類型數據完全相同的可能性是在這1/300秒內生成的兩個GUID前10個字節完全相同，這幾乎是不可能的！在SQL Server中用SQL命令將這一思路實現出來便是：
DECLARE @aGuid UNIQUEIDENTIFIER SET @aGuid = CAST(CAST(NEWID() AS BINARY(10)) + CAST(GETDATE() AS BINARY(6)) AS UNIQUEIDENTIFIER)
經過測試，使用COMB做主鍵比使用INT做主鍵，在檢索、插入、更新、刪除等操作上仍然顯慢，但比Unidentifier類型要快上一些。