主鍵總是從1開始？

我正在遷移舊數據庫（oracle），並且有幾個表，如CountryCode,DeptCode和RoleCodes，它們的主鍵是字符串（Codes），我正在考慮將Number列添加爲主鍵，因爲它可以快速使用joins 。這些表格並不是很大。主鍵總是從1開始？

我想知道如果這些表的主鍵應該從數字'1'開始，或者它可以從100開始只是爲了區分黑白表PK，但我不認爲我會在報告中顯示它們。

來源

2012-07-19 user1263981

您通常可以在表設計器（MSSQL服務器）中設置初始種子 - 這是完全可以做到的。 – 2012-07-19 11:04:32

主鍵的值是什麼並不重要。只要一個*單*表不包含重複的鍵。兩個表的兩個主鍵之間的關係不應該打擾你。您應該只考慮一個表的主鍵和另一個表的外鍵（這些必須匹配）。 – oleksii 2012-07-19 11:08:10

對於序列生成的ID，我建議從不同的值開始，如果它很容易做（取決於您的數據庫等）。你不應該用這個來區分代碼，但它可以使測試更合理。

在此之前，我有一種情況，我不小心使用了外鍵一個表好像它是另一個表的外鍵。測試通過的身份證號碼爲，巧合的是相同。當我們發現問題後，我們改變了最初的種子，發現測試更清晰了。

來源

2012-07-19 11:06:30

主鍵從哪裏開始無關緊要。假設代碼沒有定期更新，我不相信int會更快。它更依賴於它是一個varchar還是一個已知的大小。

來源

2012-07-19 11:04:26

您不應該這樣做來區分表格。這是不實際的。

並非所有主鍵都必須從1開始，如訂單號的情況。

來源

2012-07-19 11:04:32

如果PK從不同的範圍開始，那麼它有助於測試報告。 – user1263981 2012-07-19 11:17:15

我個人總是有一個字段名稱「Id」作爲表的主鍵，如果需要定義爲int或bigInt。

如果表達枚舉類型匹配，那麼我保證ID的EnumeratedType ID可以是任何數量的匹配 - 所以沒有它不需要如果沒有從1

啓動匹配一個枚舉類型，那麼我通常會使用從1開始的自動遞增鍵，但這並不總是需要的。

注意 - 如果行數很少，那麼數字和varchar上的索引之間的差異可以忽略不計。

來源

2012-07-19 11:05:46 BonyT

但是代碼正在使用的表格非常大，所以您認爲JOINS在主鍵上運行得更快（Varchar2數據類型） – user1263981 2012-07-19 11:12:37

我不知道「big」是什麼意思，但是是 - 使用整數代替連接的varchar會更快 - 表格越大，性能差異越大。就我個人而言，我儘量不要加入ID。 – BonyT 2012-07-19 12:48:09

例如在ERP系統中定義代表某一組項目的數字範圍是很常見的。

這可以是位置更大的數字，例如

1234567890 
    | | 
    index 4 - 6 represents region code 
    index 7 - 8 represents dept code...

，或者我在你的情況下懷疑，部分在同一個地方，像

1000 - 1999 Region codes 
2000 - 2999 DeptCode 
3000 - 3999 RoleCode

因此：不，這並不一定與1

更大的ERP系統開始甚至已經數字範圍的配置部分！

現在，從數據庫的觀點：

是的，你的表應該始終有一個主鍵！有人會在平均情況下顯着提高性能。（但在大多數數據庫系統，如果你不提供一個，一會通過看不到和無法處理的DBMS設置。有些DBMS甚至創建指數，但那是另一回事）

來源

2012-07-19 11:06:36

是，它起始於哪個整數並不重要，它主要用於定義唯一的行和其他表之間的關係。

來源

2012-07-19 11:11:41 Samar

我認爲沒有關係的起始數字或起始值將保存主鍵。
重要的是，它們將在連接表的FK中以與MAIN表中的PK相同的值表示。

來源

2012-07-19 11:15:29

你用來切換到整數主鍵的基本原理似乎並不合理：使用INT而不是原始代碼（我假設它是字符串）將會看到的性能增益可以忽略不計。 PK總是編入索引，並且字符串或數字的索引與瞬時一樣好。所以除非你真的需要INT，否則我會試圖堅持原始數據類型並使用原始數據 - 簡化數據遷移（這是在做任何工作時應該考慮的事情）。

來源

2012-07-19 11:32:29

謝謝，這就是我只是想着。另外，這是否可以將EmpCode（Varchar2）作爲PK？該表中大約有600行參考時間表和員工歷史表。 – user1263981 2012-07-19 11:35:45

我不明白爲什麼不。提出參考數據表時，索引的選擇比編碼字段是字符串還是數字更重要。如果整數更快，那只是因爲它們是固定的4字節值，而字符串的長度可能是隨機的（直到字符串字段的最大大小）。所以如果你的編碼字段是（比如說）VARCHAR2（10），那麼就沒有問題了。我擔心，如果字符串大小顯着更長，但它不是一個真正的代碼（「代碼」意味着一個短的字符串）。 – 2012-07-19 12:06:43

但是，隱藏主鍵（如int或guid）的好處是，您可以稍後更改代碼列的值，而不會破壞外鍵指向該代碼的所有現有數據。 – 2012-07-19 12:23:55

代理鍵可以具有任何值，只要它們是唯一的。這就是最終讓它「替代」的原因 - 價值觀本身並沒有內在的意義，通常也不應該向用戶展示。這就是說，你可以考慮使用不同的種子，僅用於測試目的，如Jon Skeet suggested。

這就是說，你真的需要引入一個新的（代理）密鑰？現有的自然鑰匙實際上可能會導致減少 JOINS，並且可能對clustering有用。雖然代理鍵有legitimate uses，但不要僅僅因爲它是「時髦的」就這樣做 - 總是要意識到您正在做出的折衷，併爲您的具體需求選擇適當的平衡點。

它會自動「傳播」下降外鍵，這樣你就不需要子表JOIN父只是爲了讓自然鍵 - 自然鍵已經在孩子。

來源

2012-07-19 12:15:09

+1，但是代孕代孕的是什麼取代了一個自然的關鍵。（*代孕*代表「代替」或「代替」某事。） – 2012-07-19 14:20:18

@Catcall我真的不能說英語，因爲它不是我的母語。但在數據庫中，代理不僅僅是替代品，它代替了不同的_quality_。交替鍵可以很容易地取代主鍵，但我們不（必然）稱之爲「代理」。如果它的值有一定的質量（缺乏意義），我們只稱它爲代理。 – 2012-07-20 00:06:21

主鍵總是從1開始？

回答

相關問題