學習作業(yè)2：問題1：主鍵都有哪些方式？問題2：本次實戰(zhàn)案例建立的主鍵采用哪種方式？問題3：猜猜金蝶K3WISE建立的主鍵采用哪種方式？問題4：談談手工主鍵增長設置具體實現(xiàn)思路？（選答）問題5：GUID主鍵是啥玩意？（選答）==========================================================================================知識點：1、創(chuàng)建主鍵的三種方法方法一:CREATETABLE學生( 學號char(6)NOTNULLprimarykey, 姓名char(8)NOTNULL, 性別char(2)NOTNULL, 出生日期smalldatetimeNOTNULL, 班級編號char(10)NOTNULL, 學分numeric(8,1)NOTNULL, 區(qū)域char(4)NOTNULL, 校名char(24)NOTNULL)ON[PRIMARY]方法二:CREATETABLE學生( 學號char(6)NOTNULL, 姓名char(8)NOTNULL, 性別char(2)NOTNULL, 出生日期smalldatetimeNOTNULL, 班級編號char(10)NOTNULL, 學分numeric(8,1)NOTNULL, 區(qū)域char(4)NOTNULL, 校名char(24)NOTNULL CONSTRAINTPK_student_idPRIMARYKEY(學號))ON[PRIMARY]方法三:(建完表再添加主鍵)CREATETABLE學生( 學號char(6)NOTNULL, 姓名char(8)NOTNULL, 性別char(2)NOTNULL, 出生日期smalldatetimeNOTNULL, 班級編號char(10)NOTNULL, 學分numeric(8,1)NOTNULL, 區(qū)域char(4)NOTNULL, 校名char(24)NOTNULL)ON[PRIMARY]altertable學生addCONSTRAINTPK_student_idPRIMARYKEY(學號)--聯(lián)合主鍵把兩列設置成一個主鍵CREATETABLEbook(bidINT,bnameVARCHAR(100),authorVARCHAR(30),CONSTRAINTpk_bid_bnamePRIMARYKEY(bid,bname))==========================================================================================2、什么是主鍵？一個表的主鍵是唯一標識，不能有重復，不允許為空。舉例1：在數(shù)據(jù)表中，比如在學生表里面，把ID字段設為主鍵。錄入學生小林，ID為1436。再錄入小張，ID為1437。執(zhí)行結果：由于小林和小張ID是不相同的，所以，都可以錄入成功。舉例2：現(xiàn)在，你再錄入學生小黃，ID為1436，這時候會錄入失敗，產(chǎn)生消息預警提示。執(zhí)行結果：原因是ID作為主鍵，必須保證每一條記錄的ID是唯一值，不能出現(xiàn)重復值。因為小林和小黃的ID相同，導致后面錄入的小黃就錄入不成功。========================================================================================================3、什么是組合主鍵？一個表的主鍵可以由一個字段或多個字段共同組成。舉例1：在數(shù)據(jù)表中，比如在學生表里面，把ID、姓名設為組合主鍵。錄入學生小林，ID為1436。再錄入小張，ID為1437。執(zhí)行結果：由于小林和小張ID、姓名都不相同，所以，都可以錄入成功。舉例2：現(xiàn)在，再錄入學生小黃，ID為1436。執(zhí)行結果：由于小林和小黃雖然ID相同，但是他們姓名不同，沒有構成唯一性重復的條件。小黃也可以錄入成功。（跟單個字段主鍵的區(qū)別是，單個字段主鍵是主鍵字段重復，就不可重復錄入。組合主鍵，其中有一個字段重復，還是可以錄入成功）舉例3：現(xiàn)在，再錄入學生小林，ID為1436。執(zhí)行結果：由于學生小林的ID和姓名都已存在，不可重復錄入，錄入失敗。========================================================================================================4、SQLGUID和自增列做主鍵的優(yōu)缺點我們公司的數(shù)據(jù)庫全部是使用GUID做主鍵的，很多人習慣使用int做主鍵。所以呢，這里總結一下，將兩種數(shù)據(jù)類型做主鍵進行一個比較。使用INT做主鍵的優(yōu)點：1、需要很小的數(shù)據(jù)存儲空間，僅僅需要4byte。2、insert和update操作時使用INT的性能比GUID好，所以使用int將會提高應用程序的性能。3、index和Join操作，int的性能最好。4、容易記憶。5、支持通過函數(shù)獲取最新的值，如：Scope_Indentity()。使用INT做主鍵的缺點1、如果經(jīng)常有合并表的操作，就可能會出現(xiàn)主鍵重復的情況。2、使用INT數(shù)據(jù)范圍有限制。如果存在大量的數(shù)據(jù)，可能會超出INT的取值范圍。（可以使用bigint）3、很難處理分布式存儲的數(shù)據(jù)表。使用GUID做主鍵的優(yōu)點：1、它是獨一無二的。2、出現(xiàn)重復的機會少。3、適合大量數(shù)據(jù)中的插入和更新操作。4、跨服務器數(shù)據(jù)合并非常方便。使用GUID做主鍵的缺點：1、存儲空間大（16byte），因此它將會占用更多的磁盤大小。2、很難記憶。join操作性能比int要低。3、沒有內置的函數(shù)獲取最新產(chǎn)生的guid主鍵。4、GUID做主鍵將會添加到表上的所有其他索引中，因此會降低性能。總結：上面列出了GUID和INT兩種數(shù)據(jù)類型做主鍵優(yōu)缺點。我覺得，對于大數(shù)據(jù)量，建議使用guid做主鍵。而使用int會得到最佳的性能。========================================================================================================5、淺析主鍵自增長的優(yōu)缺點主鍵應該怎樣設計？目前主要用到的主鍵方案共三種自動增長主鍵手動增長主鍵UNIQUEIDENTIFIER主鍵1、先說自動增長主鍵,它的優(yōu)點是簡單,類型支持bigint.但是它有致命的弱點:當我們需要在多個數(shù)據(jù)庫間進行數(shù)據(jù)的復制時（SQLServer的數(shù)據(jù)分發(fā)、訂閱機制允許我們進行庫間的數(shù)據(jù)復制操作），自動增長型字段可能造成數(shù)據(jù)合并時的主鍵沖突。設想一個數(shù)據(jù)庫中的Order表向另一個庫中的Order表復制數(shù)據(jù)庫時，OrderID到底該不該自動增長呢？2、再說手動增長主鍵,它的優(yōu)點是自行定制主鍵列,主鍵列的數(shù)據(jù)類型乃至數(shù)據(jù)樣本都可以控制,能夠穩(wěn)定的獲得目標鍵值,不會重復.但是它維護成本比較搞,首先生成鍵值需要自行編寫存儲過程來產(chǎn)生,網(wǎng)絡開銷大,運行時還要考慮到并發(fā)沖突等等.3、最后就是UNIQUEIDENTIFIER主鍵,它利用GUID作為鍵值,可以直接調用newid()來獲得全局唯一標識,即便合并數(shù)據(jù)表也不會有重復現(xiàn)象.但是UGID有兩個弱點:其一,和int類型比較,GUID長度是前者4倍.其二,用newid()獲得的GUID毫無規(guī)律,因為該列作為主鍵,必然有聚集索引,那么在插入新數(shù)據(jù)時,將是一個非常耗時的操作.這樣的話UNIQUEIDENTIFIER作為主鍵將大大有損效率.所以SQLServer2000環(huán)境下DBA們往往寫一個存儲過程來生成與時間有關的GUID,即在GUID前面加上生成時間.這樣確保生成出來的主鍵全局唯一并且按時間遞增.不過這又回到了第二種主鍵方案,不便維護.4、SQLServer提供了新的解決方法,使用的是NEWSEQUENTIALID()，這個函數(shù)產(chǎn)生的GUID是遞增的，下面看下它的用法--創(chuàng)建實驗表--1創(chuàng)建id列的類型為UNIQUEIDENTIFIER--2ROWGUIDCOL只是這個列的別名,一個表中只能有一個--3PRIMARYKEY確定id為主鍵--4使用DEFAULT約束來自動為該列添加GUIDcreatetablejobs( idUNIQUEIDENTIFIERROWGUIDCOLPRIMARYKEYNOTNULL CONSTRAINT[DF_jobs_id]DEFAULT(NEWSEQUENTIALID()), accountvarchar(64)notnull, [password]varchar(64)notnull)select*fromjobs--添加實驗數(shù)據(jù)insertjobs(account,[password])values('tudou','123')insertjobs(account,[password])values('ntudou','123')insertjobs(account,[password])values('atudou','123')insertjobs(account,[password])values('btudou','123')insertjobs(account,[password])values('ctudou','123')select*fromjobs========================================================================================6、關于數(shù)據(jù)庫設計中主鍵問題的思考數(shù)據(jù)庫主鍵在數(shù)據(jù)庫中占有重要地位。主鍵的選取策略決定了系統(tǒng)是否可靠、易用、高效。本文探討了數(shù)據(jù)庫設計過程當中常見的主鍵選取策略，并剖析了其做主鍵的優(yōu)缺點，提出了相應的解決問題的方法在基于關系型數(shù)據(jù)庫設計時候，通常要為每張表指定一個主鍵，所謂主鍵就是能夠唯一標識表中某一行記錄的屬性或屬性組，一個表只能有一個主鍵，但可以有多個候選索引。因為主鍵可以唯一標識某一行記錄，所以可以確保執(zhí)行數(shù)據(jù)更新、刪除、修改時不出現(xiàn)錯誤。當然，其它字段可以輔助我們在執(zhí)行這些操作時消除共享沖突，不是本文討論的重點，不再贅述。主鍵除了上述作用外，常常與外鍵構成參照完整性約束，防止出現(xiàn)數(shù)據(jù)不一致。所以數(shù)據(jù)庫在設計時，主鍵起到了很重要的作用。常見的數(shù)據(jù)庫主鍵選取方式有：自動增長式、手動增長式、UniqueIdentifier、聯(lián)合式（復合式）、時間序列+隨機數(shù)式、“COMB（Combine）”類型。一、自動增長式很多數(shù)據(jù)庫設計者喜歡使用自動增長型字段，因為它使用簡單。自動增長式允許我們在向數(shù)據(jù)庫添加數(shù)據(jù)時，不考慮主鍵的取值，記錄插入后，數(shù)據(jù)庫系統(tǒng)會自動為其分配一個值，確保絕對不會出現(xiàn)重復。如果使用SQLServer數(shù)據(jù)庫的話，我們還可以在記錄插入后使用@@IDENTITY全局變量獲取系統(tǒng)分配的主鍵值。

盡管自動增長式字段會省掉我們很多繁瑣的工作，但使用它也存在潛在的問題，那就是在數(shù)據(jù)緩沖模式下，很難預先填寫主鍵與外鍵的值。假設有主輔兩張表：Order(OrderID,OrderDate)訂單表

OrderDetial(OrderID,LineNum,ProductID,Price)訂單明細表Order表中的OrderID是自動增長型的字段。假設現(xiàn)在需要我們錄入一張訂單，包括在Order表中插入一條記錄以及在OrderDetail表中插入若干條記錄。因為Order表中的OrderID是自動增長型的字段，那么我們在記錄正式插入到數(shù)據(jù)庫之前無法事先得知它的取值，只有在更新后才能知道數(shù)據(jù)庫為它分配的是什么值。這會造成以下矛盾發(fā)生：

首先，為了能在OrderDetail的OrderID字段中添入正確的值，必須先更新Order表以獲取到系統(tǒng)為其分配的OrderID值，然后再用這個OrderID填充OrderDetail表的OrderID列。最后更新OderDetail表。但是，為了確保數(shù)據(jù)的一致性，Order與OrderDetail在更新時必須在事務模式下進行的，即要么兩張表同時同時更新成功、要么全部失敗，顯然它們是相互矛盾的。

其次，當我們需要在多個數(shù)據(jù)庫間進行數(shù)據(jù)的復制時（SQLServer的數(shù)據(jù)分發(fā)、訂閱機制允許我們進行庫間的數(shù)據(jù)復制操作），自動增長式字段可能造成數(shù)據(jù)合并時的主鍵沖突及表關聯(lián)關系的丟失。設想一個數(shù)據(jù)庫中的Order表向另一個庫中的Order表復制數(shù)據(jù)庫時，OrderID到底該不該自動增長呢？如果自動增長，其子表OrderDetial的關聯(lián)關系會丟失，如果不增長就會和現(xiàn)有數(shù)據(jù)主鍵重復，是不是很矛盾呢？

再次，自增量的值都是需要在系統(tǒng)中維護一個全局的數(shù)據(jù)值，每次插入數(shù)據(jù)時即對此次值進行增量取值。當在產(chǎn)生唯一標識的并發(fā)環(huán)境中，每次的增量取值都必須為此全局值加鎖解鎖以保證增量的唯一性。造成并發(fā)瓶頸，降低查詢性能。

還有當數(shù)據(jù)表足夠大或頻繁的更改和插入操作導致主鍵類型值超出范圍，這種情況一般很少碰到，但也是我們進行數(shù)據(jù)表設計時必須考慮的一個問題二、手動增長型字段既然自動增長型字段會帶來如此的麻煩，我們不妨考慮使用手動增長型的字段，也就是說主鍵的值需要自己維護，通常情況下需要建立一張單獨的表存儲當前主鍵鍵值。為了敘述上的方便仍然利用上面的例子進行闡述，新建一張表叫IntKey，包含兩個字段，KeyName以及KeyValue。就像一個HashTable，給一個KeyName，就可以知道目前的KeyValue是什么，然后手工實現(xiàn)鍵值數(shù)據(jù)遞增。在SQLServer中可以編寫這樣一個存儲過程，讓取鍵值的過程自動進行。代碼如下：CREATEPROCEDURE[GetKey]@KeyNamechar(10),@KeyValueintOUTPUTASUPDATEIntKeySET@KeyValue=KeyValue=KeyValue+1WHEREKeyName=@KeyNameGO這樣，通過調用存儲過程，我們可以獲得最新鍵值，確保不會出現(xiàn)重復。若將OrderID字段設置為手動增長式字段，我們的程序可以由以下幾步來實現(xiàn)：首先調用存儲過程，獲得一個OrderID，然后使用這個OrderID填充Order表與OrderDetail表，最后在事務機制下對兩表進行更新。

使用手動增長式字段作為主鍵在進行數(shù)據(jù)庫間數(shù)據(jù)復制時，可以確保數(shù)據(jù)合并過程中不會出現(xiàn)鍵值沖突，只要為不同的數(shù)據(jù)表分配不同的主鍵取值段就行了。但是，使用手動增長型字段會增加網(wǎng)絡的負擔，必須通過增加一次數(shù)據(jù)庫訪問來獲取當前主鍵鍵值，這會增加網(wǎng)絡和數(shù)據(jù)庫的負載，當處于一個低速或斷開的網(wǎng)絡環(huán)境中時，這種做法會有很大的弊端。同時，手工維護主鍵還要考慮并發(fā)沖突等種種因素，這更會增加系統(tǒng)的復雜程度。三、使用UniqueIdentifierSQLServer為我們提供了UniqueIdentifier數(shù)據(jù)類型，并提供了一個生成函數(shù)NEWID()，使用NEWID()可以生成一個唯一的UniqueIdentifier。UniqueIdentifier在數(shù)據(jù)庫中占用16個字節(jié)，出現(xiàn)重復的概率幾乎為0，號稱全球唯一標識。我們經(jīng)常從注冊表或WINDOWS程序出現(xiàn)錯誤需要調試時看到類似768427bf-9b37-4776-97ca-000365e160d5或{45F0EB02-0727-4F2E-AAB5-E8AEDEE0CEC5}的東西實際上就是一個UniqueIdentifier，Windows用它來做COM組件以及接口的標識，防止出現(xiàn)重復。在.NET中UniqueIdentifier稱之為GUID（GlobalUniqueIdentifier）。在C#中可以使用如下命令生成一個GUID：

Guidu=System.Guid.NewGuid();

對于上面提到的Order與OrderDetail的程序，如果選用UniqueIdentifier作為主鍵的話，我們完全可以避免上面提到的增加網(wǎng)絡RoundTrip的問題。通過程序直接生成GUID填充主鍵，不用考慮是否會出現(xiàn)重復。但是UniqueIdentifier字段也存在嚴重的缺陷：首先，它的長度是16字節(jié)，是整數(shù)的4倍長，會占用大量存儲空間。更為嚴重的是，UniqueIdentifier的生成毫無規(guī)律可言，也就是說是無序的，要想在上面建立索引（絕大多數(shù)數(shù)據(jù)庫在主鍵上都有索引）是一個非常耗時的操作。有人做過實驗，當數(shù)據(jù)表記錄比較大的時，在不同的數(shù)據(jù)量級別上插入同樣的數(shù)據(jù)量，使用UniqueIdentifier型數(shù)據(jù)做主鍵要比使用Integer型數(shù)據(jù)慢，且還沒有考慮到表關聯(lián)的情況，出于效率考慮，盡可能避免使用UniqueIdentifier型數(shù)據(jù)庫作為主鍵值，但隨著現(xiàn)代計算機計算速度越來越快，在中小型項目中使用UniqueIdentifier式主鍵也是一個選項。四、使用業(yè)務字段聯(lián)合主鍵

基于DEPHI和POWERBUILDER等數(shù)據(jù)庫工具開發(fā)C/S系統(tǒng)的數(shù)據(jù)庫設計人員，習慣上用有業(yè)務意義的字段組合成復合主鍵做數(shù)據(jù)表主鍵。使用業(yè)務主鍵當然有其與生俱來的好處，一般情況下數(shù)據(jù)庫系統(tǒng)會在默認條件下建立聚簇索引，而且這個聚簇索引基于主鍵升序排列，當數(shù)據(jù)量比較小時，我們感覺不到這種差別，當數(shù)據(jù)量比較大時，這種基于主鍵定義的聚簇索引的優(yōu)勢就顯現(xiàn)出來，這就使得數(shù)據(jù)表在每次存取數(shù)據(jù)時按照索引準確確認數(shù)據(jù)插入或更新的磁盤物理位置，減少磁頭尋址時間，從而提高數(shù)據(jù)庫性能，而且能夠從業(yè)務意義上保證數(shù)據(jù)的完整性，增加程序的可靠性。但是基于業(yè)務字段的聯(lián)合索引，當業(yè)務字段選用比較多時會占用比較多的磁盤空間，而且索引頁會占用更多的內存頁面，從而導致查詢命中率降低；另外使用業(yè)務主鍵，當涉及到主鍵數(shù)據(jù)的修改時，要在編程過程中記錄新值和原值的關系表，在更新時又要進行新值和原值的比對，增加編寫程序的復雜度。五、時間序列+主鍵采用精確到毫秒甚至鈉秒隨機數(shù)級的時間和一個隨機產(chǎn)生的兩位數(shù)做主鍵，如200911282311528+兩位隨機數(shù)，不失為解決主鍵問題的一個有效辦法。這樣產(chǎn)生的主鍵既避免了UniqueIdentifier型字段做主鍵時的無序，又能有效避免自動增長型主鍵帶來的諸如復制和數(shù)據(jù)導入的麻煩。但在使用用戶眾多的網(wǎng)絡實時系統(tǒng)中，在時間和空間上仍然不能保證唯一性的問題。六、使用“COMB（Combine）”類型既然上面五種主鍵類型選取策略都存在各自的缺點，那么到底有沒有好的辦法加以解決呢？答案是肯定的。通過使用COMB類型（數(shù)據(jù)庫中沒有COMB類型，它是JimmyNilsson在他的“TheCostofGUIDsasPrimaryKeys”一文中設計出來的），可以在以上眾多的主鍵策略之間采用中庸之道，找到一個很好的平衡點。COMB數(shù)據(jù)類型的基本設計思路是這樣的：既然UniqueIdentifier數(shù)據(jù)因毫無規(guī)律可言造成索引效率低下，影響了系統(tǒng)的性能，那么我們能不能通過組合的方式，保留UniqueIdentifier的前10個字節(jié)，用后6個字節(jié)表示GUID生成的時間（DateTime），這樣我們將時間信息與UniqueIdentifier組合起來，在保留UniqueIdentifier的唯一性的同時增加了有序性，以此來提高索引效率。也許有人會擔心UniqueIdentifier減少到10字節(jié)會造成數(shù)據(jù)出現(xiàn)重復，其實不用擔心，后6字節(jié)的時間精度可以達到1/300秒，兩個COMB類型數(shù)據(jù)完全相同的可能性是在這1/300秒內生成的兩個GUID前10個字節(jié)完全相同，這幾乎是不可能的！在SQLServer中用SQL命令將這一思路實現(xiàn)出來便是：DECLARE@aGuidUNIQUEIDENTIFIERSET@aGuid=CAST(CAST(NEWID()ASBINARY(10))+CAST(GETDATE()ASBINARY(6))ASUNIQUEIDENTIFIER)經(jīng)過測試，使用COMB做主鍵比使用INT做主鍵，在檢索、插入、更新、刪除等操作上仍然顯慢，但比Unidentifier類型要快上一些。除了使用存儲過程實現(xiàn)COMB數(shù)據(jù)外，我們也可以使用C#生成COMB數(shù)據(jù)，這樣所有主鍵生成工作可以在客戶端完成。C#代碼如下：//================================================/**////<summary>///返回GUID用于數(shù)據(jù)庫操作，特定的時間代碼可以提高檢索效率///</summary>///<returns>COMB(GUID與時間混合型)類型GUID數(shù)據(jù)</returns>publicstaticGuidNewComb(){byte[]guidArray=System.Guid.NewGuid().ToByteArray();DateTimebaseDate=newDateTime(1900,1,1);DateTimenow=DateTime.Now;//GetthedaysandmillisecondswhichwillbeusedtobuildthebytestringTimeSpandays=newTimeSpan(now.Ticks-baseDate.Ticks);TimeSpanmsecs=newTimeSpan(now.Ticks-(newDateTime(now.Year,now.Month,now.Day).Ticks));//Converttoabytearray//NotethatSQLServerisaccurateto1/300thofamillisecondsowedivideby3.333333byte[]daysArray=BitConverter.GetBytes(days.Days);byte[]msecsArray=BitConverter.GetBytes((long)(msecs.TotalMilliseconds/3.333333));//ReversethebytestomatchSQLServersorderingArray.Reverse(daysArray);Array.Reverse(msecsArray);//CopythebytesintotheguidArray.Copy(daysArray,daysArray.Length-2,guidArray,guidArray.Length-6,2);Array.Copy(msecsArray,msecsArray.Length-4,guidArray,guidArray.Length-4,4);returnnewSystem.Guid(guidArray);}//================================================/**////<summary>///從SQLSERVER返回的GUID中生成時間信息///</summary>///<paramname="guid">包含時間信息的COMB</param>///<returns>時間</returns>publicstaticDateTimeGetDateFromComb(System.Guidguid){DateTimebaseDate=newDateTime(1900,1,1);byte[]daysArray=newbyte[4];byte[]msecsArray=newbyte[4];byte[]guidArray=guid.ToByteArray();//Copythedatepartsoftheguidtotherespectivebytearrays.Array.Copy(guidArray,guidArray.Length-6,daysArray,2,2);