爲了真正理解按鍵,您必須在三個層次上理解它們:概念,邏輯和物理。我要扭轉我的慣常秩序,首先討論身體。
大多數程序員傾向於在物理層面思考。在物理層面,一個關鍵是一個地址的代理(替代)。當要引用一行時,可以使用該鍵的副本來指定該行。當在另一行中引用一行時,該副本被稱爲外鍵。
大多數有經驗的程序員都對指針和地址有一個透徹的理解,並且只要它使用指針和地址就能準確理解數據結構是如何工作的。在關係數據庫成爲主導之前,實際上有數據庫使用指向嵌入在其他記錄中的記錄的指針來將數據綁定在一起。
使用鍵而不是指針的一個缺點是DBMS必須使用索引將鍵引用轉換回指針才能檢索有問題的行。一個好處是,只要DBMS相應地更新所有相關索引,間接級別就允許DBMS無論出於何種目的都對錶中的所有行進行整理。
在這個級別上看,鍵可能是簡單的,整數和自動增量。這些工作比其他類型的鍵快,並且避免了用戶提供的數據丟失或不一致時出現的某些數據管理問題。但是,在這個層面迴避數據管理問題可以在兩個較高層次上創建一個雷區。
在邏輯層面上,鍵是元組(行)中數據的最小子集,允許指定單個匹配元組,當DBMS檢索該元組的容器時,該元組中的所有屬性元組現在可用。每個關係至少有一個候選關鍵字。在最壞的情況下,整個元組是唯一的候選鍵。當單個關係(表)存在多個候選鍵時,通常的做法是選擇一個候選鍵作爲主鍵,並通過該主鍵進行所有引用。
(其實,關係和表不是同義詞,但我在這裏簡單化。同樣,元組和行不是同義詞,儘管它們看起來乍看是相同的。)
的主要原因申報初級關鍵是排除重複的鍵或丟失的鍵。 有時,數據庫人員會選擇將重複和丟失鍵保留給應用程序寫入數據庫的程序員。更常見的情況是,主鍵約束用於將錯誤反映回違反主鍵約束的程序。
當DBMS設置主鍵約束時,它還會在主鍵上構建索引。這允許DBMS快速查找重複項,並且還可以加快使用關鍵列的某些查詢。
在概念層面,關鍵是通過用戶社區標識實體實例的方式,這些實體是否者(員工,旅客等),東西(銀行帳戶,酒店客房等)或任何。密鑰是數據,密鑰標識的實體不是數據。因此可以將密鑰視爲數據庫中實體的替代物。
在概念層次,按鍵總是自然,也不會被系統自動供給。然而,在現實世界中,鑰匙往往管理不善,而管理不善的後果則被所謂的「常識」所克服。將常識灌輸到自動化系統中通常是不可行的。
我從來沒有真正在上述的指數,但它在我所說的隱式的。索引是一個數據結構,用於從一個鍵映射到一個指針。在您可能使用的所有數據庫中,索引由數據庫構建器(或者DBA)聲明並由DBMS管理。
謝謝你,一個基本的瞭解是所有我真的找了,我只是想確保我做出了正確的決定(並能保持作出正確的決定),當我添加一鍵表 – 2010-01-05 19:01:44
很好的回答。 FWIW,一些RDBMS允許具有唯一約束的列中有多個NULL。而你並沒有包括外鍵。 – 2010-01-05 19:02:15
比爾,因爲我剛剛注意到,OP是關於MySQL(這是允許多個空值具有唯一約束的RDBMS中的一個)明確要求,我將修改我的答案...你說得對。但OP沒有詢問外鍵...... – delfuego 2010-01-05 19:05:16