Oracle創建主鍵優劣
創建主鍵方式
一個表的主鍵是唯一標識，不能有重複，不允許為空。
-- 列級，表級建立主鍵 1.create table constraint_test ( name_id number not null constraint cons_name_id primary key, old number ) 2.create table constraint_test ( name_id number primary key, old number ) drop table constraint_test; 3.create table constraint_test ( name_id number not null, old number , constraint cons_name_id primary key ( name_id ) ); drop table constraint_test; 4.create table constraint_test ( name_id number not null, old number ); alter table constraint_test add constraint cons_name_id primary key ( name_id );
drop table course ; drop table students ; create table students (code number , name varchar2(10), country varchar2(30) ); alter table students add constraint pk_st_cod primary key ( code); insert into students values(0001,'zhangsan','shanghai'); insert into students values(0002,'lisi','beijing'); insert into students values(0003,'wangwu','guangzhou'); create table course (id number, code number, name varchar2(10), subject varchar2(30) ); alter table course add constraint pk_co_id primary key ( id); alter table course add constraint fk_co_st foreign key ( code) references students(code); alter table students add foreign key pk_co_id on id; inser into course(id,code,name,subject) values(1,001,'zhangsan','yuwen'); inser into course(id,code,name,subject) values(2,001,'zhangsan','shuxue');
總結
SQL GUID和自增列做主鍵的優缺點
我們公司的資料庫全部是使用GUID做主鍵的，很多人習慣使用int做主鍵。所以呢，這裡總結一下，將兩種數據類型做主鍵進行一個比較。
使用INT做主鍵的優點：
1、需要很小的數據存儲空間，僅僅需要4 byte 。
2、insert和update操作時使用INT的性能比GUID好，所以使用int將會提高應用程式的性能。
3、index和Join 操作，int的性能最好。
4、容易記憶。
5、支援通過函數獲取最新的值，如：Scope_Indentity() 。
使用INT做主鍵的缺點
1、如果經常有合併表的操作，就可能會出現主鍵重複的情況。
2、使用INT數據範圍有限制。如果存在大量的數據，可能會超出INT的取值範圍。（可以使用bigint）
3、很難處理分散式存儲的數據表。
使用GUID做主鍵的優點：
1、它是獨一無二的。
2、出現重複的機會少。
3、適合大量數據中的插入和更新操作。
4、跨伺服器數據合併非常方便。
使用GUID做主鍵的缺點：
1、存儲空間大（16 byte），因此它將會佔用更多的磁碟大小。
2、很難記憶。join操作性能比int要低。
3、沒有內置的函數獲取最新產生的guid主鍵。
4、GUID做主鍵將會添加到表上的所有其他索引中，因此會降低性能。
總結：
上面列出了GUID和INT兩種數據類型做主鍵優缺點。我覺得，對於大數據量，建議使用guid做主鍵。而使用int會得到最佳的性能。
5**、淺析主鍵自增長的優缺點**
主鍵應該怎樣設計？目前主要用到的主鍵方案共三種
自動增長主鍵
手動增長主鍵
UNIQUEIDENTIFIER主鍵
1、先說自動增長主鍵,它的優點是簡單,類型支援bigint.但是它有致命的弱點:
當我們需要在多個資料庫間進行數據的複製時（SQL Server的數據分發、訂閱機制允許我們進行庫間的數據複製操作），自動增長型欄位可能造成數據合併時的主鍵衝突。設想一個資料庫中的Order表向另一個庫中的Order表複製資料庫時，OrderID到底該不該自動增長呢？
2、再說手動增長主鍵,它的優點是自行訂製主鍵列,主鍵列的數據類型乃至數據樣本都可以控制,能夠穩定的獲得目標鍵值,不會重複.但是它維護成本比較搞,首先生成鍵值需要自行編寫存儲過程來產生,網路開銷大,運行時還要考慮到並發衝突等等.
3、最後就是UNIQUEIDENTIFIER主鍵,它利用GUID作為鍵值,可以直接調用newid()來獲得全局唯一標識,即便合併數據表也不會有重複現象.但是UGID有兩個弱點:其一,和int類型比較,GUID長度是前者4倍.其二,用newid()獲得的GUID毫無規律,因為該列作為主鍵,必然有聚集索引,那麼在插入新數據時,將是一個非常耗時的操作.這樣的話UNIQUEIDENTIFIER作為主鍵將大大有損效率.
所以SQLServer2000環境下DBA們往往寫一個存儲過程來生成與時間有關的GUID,即在GUID前面加上生成時間.這樣確保生成出來的主鍵全局唯一併且按時間遞增.不過這又回到了第二種主鍵方案,不便維護.
4、SQLServer 提供了新的解決方法,使用的是NEWSEQUENTIALID()，這個函數產生的GUID是遞增的，下面看下它的用法
–創建實驗表
–1創建id列的類型為UNIQUEIDENTIFIER
–2ROWGUIDCOL只是這個列的別名,一個表中只能有一個
–3PRIMARY KEY確定id為主鍵
–4使用DEFAULT約束來自動為該列添加GUID
create table jobs
(
id UNIQUEIDENTIFIER ROWGUIDCOL PRIMARY KEY NOT NULL
CONSTRAINT [DF_jobs_id] DEFAULT (NEWSEQUENTIALID()),
account varchar(64) not null,
[password] varchar(64) not null
)
select * from jobs
–添加實驗數據
insert jobs (account , [password]) values (‘tudou’ , ‘123’)
insert jobs (account , [password]) values (‘ntudou’ , ‘123’)
insert jobs (account , [password]) values (‘atudou’ , ‘123’)
insert jobs (account , [password]) values (‘btudou’ , ‘123’)
insert jobs (account , [password]) values (‘ctudou’ , ‘123’)
select * from jobs
============================================
============================================
6**、關於資料庫設計中主鍵問題的思考**
資料庫主鍵在資料庫中佔有重要地位。主鍵的選取策略決定了系統是否可靠、易用、高效。本文探討了資料庫設計過程當中常見的主鍵選取策略，並剖析了其做主鍵的優缺點，提出了相應的解決問題的方法
在基於關係型資料庫設計時候，通常要為每張表指定一個主鍵，所謂主鍵就是能夠唯一標識表中某一行記錄的屬性或屬性組，一個表只能有一個主鍵，但可以有多個候選索引。因為主鍵可以唯一標識某一行記錄，所以可以確保執行數據更新、刪除、修改時不出現錯誤。當然，其它欄位可以輔助我們在執行這些操作時消除共享衝突，不是本文討論的重點，不再贅述。主鍵除了上述作用外，常常與外鍵構成參照完整性約束，防止出現數據不一致。所以資料庫在設計時，主鍵起到了很重要的作用。常見的資料庫主鍵選取方式有： 自動增長式、手動增長式 、UniqueIdentifier、聯合式（複合式）、時間序列+隨機數式、「COMB（Combine）」類型。
一、自動增長式
很多資料庫設計者喜歡使用自動增長型欄位，因為它使用簡單。自動增長式允許我們在向資料庫添加數據時，不考慮主鍵的取值，記錄插入後，資料庫系統會自動為其分配一個值，確保絕對不會出現重複。如果使用SQL Server資料庫的話，我們還可以在記錄插入後使用@@IDENTITY全局變數獲取系統分配的主鍵值。 儘管自動增長式欄位會省掉我們很多繁瑣的工作，但使用它也存在潛在的問題，那就是在數據緩衝模式下，很難預先填寫主鍵與外鍵的值。假設有主輔兩張表：
Order(OrderID, OrderDate) 訂單表 OrderDetial(OrderID, LineNum, ProductID, Price) 訂單明細表
Order 表中的OrderID是自動增長型的欄位。假設現在需要我們錄入一張訂單，包括在Order表中插入一條記錄以及在OrderDetail表中插入若干條記錄。因為Order表中的OrderID是自動增長型的欄位，那麼我們在記錄正式插入到資料庫之前無法事先得知它的取值，只有在更新後才能知道資料庫為它分配的是什麼值。這會造成以下矛盾發生： 首先，為了能在OrderDetail的OrderID欄位中添入正確的值，必須先更新 Order表以獲取到系統為其分配的OrderID值，然後再用這個OrderID填充OrderDetail表的OrderID列。最後更新OderDetail表。但是，為了確保數據的一致性，Order與OrderDetail在更新時必須在事務模式下進行的，即要麼兩張表同時同時更新成功、要麼全部失敗，顯然它們是相互矛盾的。 其次，當我們需要在多個資料庫間進行數據的複製時（SQL Server的數據分發、訂閱機制允許我們進行庫間的數據複製操作），自動增長式欄位可能造成數據合併時的主鍵衝突及表關聯關係的丟失。設想一個資料庫中的Order表向另一個庫中的Order表複製資料庫時，OrderID到底該不該自動增長呢？如果自動增長，其子表OrderDetial的關聯關係會丟失，如果不增長就會和現有數據主鍵重複，是不是很矛盾呢？ 再次，自增量的值都是需要在系統中維護一個全局的數據值，每次插入數據時即對此次值進行增量取值。當在產生唯一標識的並發環境中，每次的增量取值都必須為此全局值加鎖解鎖以保證增量的唯一性。造成並發瓶頸，降低查詢性能。 還有當數據表足夠大或頻繁的更改和插入操作導致主鍵類型值超出範圍，這種情況一般很少碰到，但也是我們進行數據表設計時必須考慮的一個問題
二、手動增長型欄位
既然自動增長型欄位會帶來如此的麻煩，我們不妨考慮使用手動增長型的欄位，也就是說主鍵的值需要自己維護，通常情況下需要建立一張單獨的表存儲當前主鍵鍵值。為了敘述上的方便仍然利用上面的例子進行闡述，新建一張表叫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表，最後在事務機制下對兩表進行更新。 使用手動增長式欄位作為主鍵在進行資料庫間數據複製時，可以確保數據合併過程中不會出現鍵值衝突，只要為不同的數據表分配不同的主鍵取值段就行了。但是，使用手動增長型欄位會增加網路的負擔，必須通過增加一次資料庫訪問來獲取當前主鍵鍵值，這會增加網路和資料庫的負載，當處於一個低速或斷開的網路環境中時，這種做法會有很大的弊端。同時，手工維護主鍵還要考慮並發衝突等種種因素，這更會增加系統的複雜程度。
三、使用UniqueIdentifier
SQL Server為我們提供了UniqueIdentifier數據類型，並提供了一個生成函數NEWID( )，使用NEWID( )可以生成一個唯一的UniqueIdentifier。UniqueIdentifier在資料庫中佔用16個位元組，出現重複的概率幾乎為0，號稱全球唯一標識。我們經常從註冊表或WINDOWS程式出現錯誤需要調試時看到類似 768427bf-9b37-4776-97ca-000365e160d5或{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型資料庫作為主鍵值，但隨著現代電腦計算速度越來越快，在中小型項目中使用UniqueIdentifier式主鍵也是一個選項。
四、使用業務欄位聯合主鍵 基於DEPHI和POWERBUILDER等資料庫工具開發C/S系統的資料庫設計人員，習慣上用有業務意義的欄位組合成複合主鍵做數據表主鍵。使用業務主鍵當然有其與生俱來的好處，一般情況下資料庫系統會在默認條件下建立聚簇索引，而且這個聚簇索引基於主鍵升序排列，當數據量比較小時，我們感覺不到這種差別，當數據量比較大時，這種基於主鍵定義的聚簇索引的優勢就顯現出來，這就使得數據表在每次存取數據時按照索引準確確認數據插入或更新的磁碟物理位置，減少磁頭定址時間，從而提高資料庫性能，而且能夠從業務意義上保證數據的完整性，增加程式的可靠性。但是基於業務欄位的聯合索引，當業務欄位選用比較多時會佔用比較多的磁碟空間，而且索引頁會佔用更多的記憶體頁面，從而導致查詢命中率降低；另外使用業務主鍵，當涉及到主鍵數據的修改時，要在編程過程中記錄新值和原值的關係表，在更新時又要進行新值和原值的比對，增加編寫程式的複雜度。
五、時間序列+主鍵
採用精確到毫秒甚至鈉秒隨機數級的時間和一個隨機產生的兩位數做主鍵，如200911282311528+兩位隨機數，不失為解決主鍵問題的一個有效辦法。這樣產生的主鍵既避免了UniqueIdentifier型欄位做主鍵時的無序，又能有效避免自動增長型主鍵帶來的諸如複製和數據導入的麻煩。但在使用用戶眾多的網路實時系統中，在時間和空間上仍然不能保證唯一性的問題。
六、使用「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類型要快上一些。除了使用存儲過程實現COMB數據外，我們也可以使用C#生成COMB數據，這樣所有主鍵生成工作可以在客戶端完成。
綜上述六種主鍵選取策略，筆者認為使用「COMB（Combine）」類型做主鍵是比較恰當的主鍵應用策略，但在實際使用過程中要根據客觀實踐、因時因事選取適當的主鍵，切不可生搬硬套、弄巧成拙。
最後oracle創建uuid
CREATE OR REPLACE FUNCTION get_uuid RETURN VARCHAR IS guid VARCHAR(50); BEGIN guid := lower(RAWTOHEX(sys_guid())); RETURN guid; END get_uuid;
