在我團隊中一個相當活躍的討論中，我想到了大多數人喜歡的主鍵。我們有以下幾類：Int / BigInt哪個自動增量是足夠好的主鍵。應該有至少3列組成的主鍵。id，GUID和人類可讀的行標識符都應區別對待。什么是對的PK最好的方法？這將是真棒，如果你能證明你的意見。有沒有更好的辦法，上面？編輯：任何人都具有簡單的樣品/算法產生人可讀的標識符為很好地進行擴展的行？
3 回答
素胚勾勒不出你
TA貢獻1827條經驗 獲得超9個贊
如果你打算做與偶爾連接的應用程序數據庫之間的同步，那么你應該使用的GUID為您的主鍵。它是一種用于調試的痛苦，從這種情況下，我傾向于堅持整數是自動增量如此分開。
自動增量整數應該是默認的，并沒有使用它們應該是合理的。
函數式編程
TA貢獻1807條經驗 獲得超9個贊
我沒有看到一個答案可以指出（我認為）真正的基本要點-即，主鍵可以確保您不會在表中獲得同一真實世界實體的兩個條目（例如在數據庫中建模）。該觀察有助于確定主鍵的優點和缺點。
例如，在（美國）狀態名稱和代碼表中，名稱或代碼可以是主鍵-它們構成兩個不同的候選鍵，并且選擇其中一個（通常是較短的-代碼）作為主鍵。首要的關鍵。在功能相關性（以及連接相關性-1NF到5NF）的理論中，關鍵的是候選鍵而不是主鍵。
作為反例，人名通常是主鍵的錯誤選擇。有很多人以“約翰·史密斯”（John Smith）或其他類似的名字命名；即使考慮到中間名（請記?。翰⒎敲總€人都有一個中間名，例如，我沒有），重復的空間很大。因此，人們不會將名稱用作主鍵。他們發明了諸如社會安全號（SSN）或員工號之類的人工密鑰，并使用它們來指定個人。
理想的主鍵應簡短，獨特，令人難忘且自然。在這些特征中，唯一性是強制性的；鑒于現實世界數據的限制，其他人必須靈活應對。
因此，在確定給定表的主鍵時，您必須查看該表代表什么。表中哪些集合或哪些列值集合唯一標識表中的每一行？這些是候選鍵?，F在，如果每個候選鍵由4或5列組成，那么您可能會認為這些鍵太笨拙而不能做成一個好的主鍵（主要是出于簡短的考慮）。在這種情況下，您可能會引入一個替代密鑰-一個人工生成的數字。通常（但不總是），一個簡單的32位整數足以替代代理密鑰。然后，您可以將此代理鍵指定為主鍵。
但是，您仍然必須確保將其他候選鍵（對于替代鍵也是候選鍵，以及所選的主鍵）都保持為唯一標識符-通常是通過在那些列集上設置唯一約束。
有時候，人們發現很難識別什么使行變得獨特，但是應該做些什么，因為僅僅重復一條信息并不能使它變得更真實。而且，如果您不小心并且確實得到兩（或更多）行聲稱要存儲相同的信息，然后又需要更新該信息，則有一種危險（尤其是如果您使用游標），您只會更新一行而不是每一行，因此這些行是不同步的，沒有人知道哪一行包含正確的信息。
在某些方面，這是一個很強硬的觀點。
我在需要時使用GUID并沒有特別的問題，但是它們往往很大（如16-64字節），而且使用頻率也很高。通常，一個很好的4字節值就足夠了。由于每個索引頁的值較少，因此使用4字節值的GUID會浪費磁盤空間，并且甚至減慢索引訪問數據的速度，因此索引將更深，必須讀取更多頁才能到達索引。信息。
ibeautiful
TA貢獻1993條經驗 獲得超6個贊
這只是一個宗教問題，因為人們尋求普遍的正確答案。您的團隊和該SO線程都顯示出很大的分歧這一事實應該表明，有充分的理由在不同情況下使用您描述的所有解決方案。
如果表中沒有其他屬性或一組屬性適合于唯一地標識行，則代理鍵很有用。
在可能的情況下，最好使用自然鍵，以使表更易于閱讀。自然鍵還允許從屬表中的外鍵包含實際值而不是代理ID。例如，當您需要存儲
state（CA，TX，NY）時，最好使用char(2)自然鍵而不是int。在適當的地方使用復合主鍵。
id當存在完美的復合鍵時，不要不必要地添加“ ”替代鍵（在多對多表中尤其如此）。在每個表中對三列鍵的授權都是絕對的廢話。當您需要在多個站點上保留唯一性時，GUID是一種解決方案。如果您需要主鍵中的值唯一但又不是有序或連續的，則它們也很方便。
INT vs. BIGINT：表需要主鍵的64位范圍并不常見，但是隨著64位硬件可用性的增加，它不應該成為負擔，并且可以確保您不會溢出。INT當然較小，因此，如果空間有限，則可以帶來一點優勢。
添加回答
舉報
0/150
提交
取消