怎麼分辨數據庫的主鍵和外鍵？

1、什麼是主鍵、外鍵：

關係型數據庫中的一條記錄中有若干個屬性，若其中某一個屬性組(注意是組)能惟一標識一條記錄，該屬性組就能夠成爲一個主鍵 
好比  
學生表(學號，姓名，性別，班級) 
其中每一個學生的學號是惟一的，學號就是一個主鍵 
課程表(課程編號,課程名,學分) 
其中課程編號是惟一的,課程編號就是一個主鍵 
成績表(學號,課程號,成績) 
成績表中單一一個屬性沒法惟一標識一條記錄，學號和課程號的組合才能夠惟一標識一條記錄，因此 學號和課程號的屬性組是一個主鍵 
  
成績表中的學號不是成績表的主鍵，但它和學生表中的學號相對應，而且學生表中的學號是學生表的主鍵，則稱成績表中的學號是學生表的外鍵 
  
同理 成績表中的課程號是課程表的外鍵 
  
定義主鍵和外鍵主要是爲了維護關係數據庫的完整性，總結一下：
1.主鍵是能肯定一條記錄的惟一標識，好比，一條記錄包括身份正號，姓名，年齡。

身份證號是惟一能肯定你這我的的，其餘均可能有重複，因此，身份證號是主鍵。 
2.外鍵用於與另外一張表的關聯。是能肯定另外一張表記錄的字段，用於保持數據的一致性。

好比，A表中的一個字段，是B表的主鍵，那他就能夠是A表的外鍵。

 

 

2、  主鍵、外鍵和索引的區別 

主鍵、外鍵和索引的區別？

	主鍵	外鍵	索引
定義：	惟一標識一條記錄，不能有重複的，不容許爲空	表的外鍵是另外一表的主鍵, 外鍵能夠有重複的, 能夠是空值	該字段沒有重複值，但能夠有一個空值
做用：	用來保證數據完整性	用來和其餘表創建聯繫用的	是提升查詢排序的速度
個數：	主鍵只能有一個	一個表能夠有多個外鍵	一個表能夠有多個唯一索引

 

彙集索引和非彙集索引的區別？

彙集索引必定是惟一索引。但惟一索引不必定是彙集索引。  

彙集索引，在索引頁裏直接存放數據，而非彙集索引在索引頁裏存放的是索引，這些索引指向專門的數據頁的數據。

 

 

 

 

3、數據庫中主鍵和外鍵的設計原則

主鍵和外鍵是把多個表組織爲一個有效的關係數據庫的粘合劑。主鍵和外鍵的設計對物理數據庫的性能和可用性都有着決定性的影響。

必須將數據庫模式從理論上的邏輯設計轉換爲實際的物理設計。而主鍵和外鍵的結構是這個設計過程的癥結所在。一旦將所設計的數據庫用於了生產環境，就很難對這些鍵進行修改，因此在開發階段就設計好主鍵和外鍵就是很是必要和值得的。

主鍵：

  關係數據庫依賴於主鍵---它是數據庫物理模式的基石。

  主鍵在物理層面上只有兩個用途：

        1. 唯一地標識一行。

        2. 做爲一個能夠被外鍵有效引用的對象。

  基於以上這兩個用途，下面給出了我在設計物理層面的主鍵時所遵循的一些原則：

        1. 主鍵應當是對用戶沒有意義的。若是用戶看到了一個表示多對多關係的鏈接表中的數據，並抱怨它沒有什麼用處，那就證實它的主鍵設計地很好。

        2. 主鍵應該是單列的，以便提升鏈接和篩選操做的效率。

        注：使用複合鍵的人一般有兩個理由爲本身開脫，而這兩個理由都是錯誤的。其一是主鍵應當具備實際意義，然而，讓主鍵具備意義只不過是給人爲地破壞數據庫提供了方便。其二是利用這種方法能夠在描述多對多關係的鏈接表中使用兩個外部鍵來做爲主鍵，我也反對這種作法，理由是：複合主鍵經常致使不良的外鍵，即當鏈接表成爲另外一個從表的主表，而依據上面的第二種方法成爲這個表主鍵的一部分，然，這個表又有可能再成爲其它從表的主表，其主鍵又有可能成了其它從表主鍵的一部分，如此傳遞下去，越靠後的從表，其主鍵將會包含越多的列了。

        3. 永遠也不要更新主鍵。實際上，由於主鍵除了唯一地標識一行以外，再沒有其餘的用途了，因此也就沒有理由去對它更新。若是主鍵須要更新，則說明主鍵應對用戶無心義的原則被違反了。

       注：這項原則對於那些常常須要在數據轉換或多數據庫合併時進行數據整理的數據並不適用。

        4. 主鍵不該包含動態變化的數據，如時間戳、建立時間列、修改時間列等。

        5. 主鍵應當有計算機自動生成。若是由人來對主鍵的建立進行干預，就會使它帶有除了唯一標識一行之外的意義。一旦越過這個界限，就可能產生認爲修改主鍵的動機，這樣，這種系統用來連接記錄行、管理記錄行的關鍵手段就會落入不瞭解數據庫設計的人的手中。

 

4、數據庫主鍵選取策略

咱們在創建數據庫的時候，須要爲每張表指定一個主鍵，所謂主鍵就是可以惟一標識表中某一行的屬性或屬性組，一個表只能有一個主鍵，但能夠有多個候選索引。由於主鍵能夠惟一標識某一行記錄，因此能夠確保執行數據更新、刪除的時候不會出現張冠李戴的錯誤。固然，其它字段能夠輔助咱們在執行這些操做時消除共享衝突，不過就不在這裏討論了。主鍵除了上述做用外，經常與外鍵構成參照完整性約束，防止出現數據不一致。因此數據庫在設計時，主鍵起到了很重要的做用。

常見的數據庫主鍵選取方式有：

· 自動增加字段

· 手動增加字段

· 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類型要快上一些。關於測試數據能夠參考我2004年7月21日的隨筆。

除了使用存儲過程實現COMB數據外，咱們也可使用C#生成COMB數據，這樣全部主鍵生成工做能夠在客戶端完成。C#代碼以下：

//================================================================
///<summary>
/// 返回 GUID 用於數據庫操做，特定的時間代碼能夠提升檢索效率
/// </summary>
/// <returns>COMB (GUID 與時間混合型) 類型 GUID 數據</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 中生成時間信息
/// </summary>
/// <param name="guid">包含時間信息的 COMB </param>
/// <returns>時間</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; 

}