若何辨別SQL數據庫中的主鍵與外鍵。本站提示廣大學習愛好者：（若何辨別SQL數據庫中的主鍵與外鍵）文章只能為提供參考，不一定能成為您想要的結果。以下是若何辨別SQL數據庫中的主鍵與外鍵正文
進入sqlplus
SQL> set timing on
SQL>
SQL> select count(*) from comm_human_role;
COUNT(*)
----------
866
Elapsed: 00:00:00.05
以上數字輸入分離是：Hours:Minutes:Seconds.Milliseconds
即用了0.05秒的時光履行，相當於50毫秒。
時光假如是如許的表現：00: 03: 235.78
總共用的時光為235.78秒， 不到4分鐘，所以顯示的是3分鐘（235.78秒年夜約為3分鐘55.78秒）
#設置屏幕行寬度
SQL>set linesize 190
#設置sqlplus打印履行籌劃和統計信息
SQL>set autotrace on
#設置sqlplus打印履行時光
SQL>set timing on
假如在sqlplus中湧現上面的毛病：
SP2-0027: Input is too long (> 2499 characters) - line ignored
表現sql一行的語句曾經跨越了2499個字符。
處理：
在一段sql中加“回車”，
包管每行不超2499個字符，從新履行sql語句就行了。
�保護關系數據庫的完全性，總結一下：
主鍵是能肯定一筆記錄的獨一標識，好比，一筆記錄包含身份證號，姓名，年紀。身份證號是獨一能肯定你這小我的，其他都能夠有反復，所以，身份證號是主鍵。
外鍵用於與另外一張表的聯系關系。是能肯定另外一張表記載的字段，用於堅持數據的分歧性。好比，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]
@KeyNamechar(10),
@KeyValue intOUTPUT 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 asPrimary Keys”一文中設計出來的），可以在三者之間找到一個很好的均衡點。
COMB數據類型的根本設計思緒是如許的：既然UniqueIdentifier數據因毫無紀律可言形成索引效力低下，影響了體系的機能，那末我們能不克不及經由過程組合的方法，保存UniqueIdentifier的前10個字節，用後6個字節表現GUID生成的時光（DateTime），如許我們將時光信息與UniqueIdentifier組合起來，在保存UniqueIdentifier的獨一性的同時增長了有序性，以此來進步索引效力。或許有人會擔憂UniqueIdentifier削減到10字節會形成數據湧現反復，其實不消擔憂，後6字節的時光精度可以到達1/300秒，兩個COMB類型數據完整雷同的能夠性是在這1/300秒內生成的兩個GUID前10個字節完整雷同，這簡直是弗成能的！在SQL Server頂用SQL敕令將這一思緒完成出來就是：
DECLARE @aGuidUNIQUEIDENTIFIER
SET @aGuid =CAST(CAST(NEWID() AS BINARY(10))
+ CAST(GETDATE()AS BINARY(6)) AS UNIQUEIDENTIFIER)
經由測試，應用COMB做主鍵比應用INT做主鍵，在檢索、拔出、更新、刪除等操作上依然顯慢，但比Unidentifier類型要快上一些。
以上是對SQL數據庫中的主鍵與外鍵的簡略引見，假如有收支，還請原諒！
