Mysql - 我應該使用ID列嗎？

我對最佳實踐以及數據庫引擎的工作原理有疑問。Mysql - 我應該使用ID列嗎？

假設我創建一個名爲Employee表，有以下欄目：

SS ID（主鍵）
名稱
性別
年齡

事情是..我看到很多數據庫，它的所有表都有和稱爲ID的附加列，這是一個序列號。我應該把ID字段放在我的桌子上嗎？我的意思是，它已經有一個主鍵被索引。序列號字段會使數據庫工作得更快嗎？如果我不使用它來鏈接或研究任何表格，我看不出它有什麼用處。

它有幫助嗎？如果是這樣，爲什麼，數據庫中會發生什麼？

謝謝！

編輯----- 這只是一個愚蠢的例子。忘記SS_ID，我知道有更好的方法來選擇主鍵。主要的topi是因爲我知道一些人只是要求我添加名爲ID的列，即使我知道我們不會將它用於任何SQL查詢。他們只是認爲它以某種方式幫助數據庫的性能，特別是因爲像Microsoft Access這樣的一些數據庫工具總是詢問我們是否希望它添加這個新列。

這是錯誤的，對吧？

來源

2012-05-04 João Guilherme

「它已經被索引的主鍵」哪一個？你確定你可以使其中一個獨特而不是空的嗎？然後你不需要一個int主鍵 – Niranjan

順序id的實際性能增益將取決於您如何使用表格。

如果您使用的是一些ORM框架，這些框架通常可以更好地使用整數類型的順序ID [1]，通常使用順序ID列來實現。
如果您不使用ORM框架，擁有您從不使用的id密鑰和代理ss_id密鑰，這實際上是您始終使用的密鑰，這是毫無意義的。
如果您從其他數據庫表（外鍵）引用employees，那麼使用id列的效率可能更高，因爲存儲該整數在子表中消耗的空間會少於存儲ss_id（我假設是CHAR或VARCHAR）無處不在。

在ss_id，假設它是一個社會安全號碼（看起來像它會），有可能是連接到它，你應該關心的法律&隱私問題 - 我的回答假設你有正當的理由有社會安全號碼在你的數據庫中，並且你將被合法地允許使用&存儲它們。

[1]這通常是由ORM框架依賴具有高度專用的緩存機制的事實來解釋的，這種緩存機制專爲典型的ORM使用量身定製 - 通常意味着擁有一個連續的主鍵，並讓應用程序處理實際業務身份。事實上這與考慮非常類似於這些「外鍵」考慮有關。

來源

2012-05-04 14:22:20 Romain

SS_ID只是一個例子（很糟糕，對不起）。我這樣問是因爲我知道一些人只是要求我添加名爲ID的列，如果我知道我們不會將它用於任何SQL查詢，那麼就是這樣。他們只是認爲它以某種方式幫助數據庫的性能。這是錯的，對吧？ –

那麼，正如我在我的答案中所述，它有助於數據庫性能*如果*它被用作跨表關係（外鍵）的一部分，或者*如果大多數SQL針對'id'列的表過濾器。 – Romain

@Romain：你能證明評論「這些通常有一個完整的類型的順序ID更好地工作」？ – Cylindric

如果SS的意思是「社會保障」，我強烈建議不要使用，作爲一個PK。自動遞增的身份是要走的路。

使用內置業務邏輯的密鑰是一個壞主意。許多人對提供SS信息很敏感。如果他們使用SS作爲主鍵，您的應用可能會消除部分受衆。 HIPPA等法律可能使您無法使用。

來源

2012-05-04 14:23:17 duffymo

+1建議不要存儲社會安全號碼。 – Romain

在存儲之前，您應該對SS ID進行散列或模糊處理。所以你不能用它作爲主鍵。這將是低效率和不安全的。 – Niranjan

@ngen它可以用這種方式進行加密，使其仍然可用作主鍵。由於這些ID通常很短，所以這樣做的性能並不那麼重要。 – Romain

更爲重要的（顯然）是你有一個主鍵，只要你把使用該主鍵將是唯一可識別的數據。在你的例子中，SSN是唯一可識別的，這就是銀行爲什麼使用它們並且會起作用的原因。這個例子的問題是您的員工ID很可能被用作其他表中的外鍵，這意味着您正在獲取個人信息（這是受法律保護的），並將其噴射到您的數據模型中。在這種情況下，使用「自動增量」字段可能會更好。

來源

2012-05-04 14:26:46 jray

美國社會安全號碼不充分識別。而銀行肯定不要這樣使用它們。不是每個人都有。錯誤導致重複。外國人沒有他們。它們太脆弱了，不能用作數據庫PK。

最重要的：的是死後resused

做一些研究：SSN as Primary Key

來源

2012-05-04 14:30:08 Cylindric

+1 - 我認爲這個封印。 – duffymo

取決於用例。另外，不能只是「假設」他們指的是美國數字。因此，這個答案是IMO，非常不完整。 – Romain

也許不完整，但即使有什麼似乎對我來說足夠明確。其他國家將不得不面對同樣的問題。 – duffymo