數據庫設計：電子郵件作爲表的ID

我正在研究Java Web應用程序。對於身份驗證，我需要用戶輸入他的電子郵件和密碼。現在，我正在使用JPA 2，這可能不是那麼重要。
如果電子郵件是用戶表的關鍵，那麼這將簡化我的生活。我可以做一個簡單：數據庫設計：電子郵件作爲表的ID

User selected = em.find(User.class, userEmail);

見？而且，每個電子郵件地址是唯一的，它有沒有空格等。現在，沒有人這樣做，我猜是有原因的。我也有疑問，我的意思是，它是varchar等，但你認爲這是個好主意嗎？如果不是，爲什麼？它必須是一個很好的理由，這樣的交易是不值得的。數字鍵始終是最好的，但在這裏我發現自己處理用戶的電子郵件一遍又一遍，並通過電子郵件的所有時間尋找他們，從來沒有真正使用id除了連接列等

來源

2011-02-06 arg20

我認爲這可能是因爲我沒有想太多，我可能有成千上萬的用戶和毫秒的聯接，並且一個varchar鍵和一個數字鍵會導致很大的空間浪費，但是有沒有其他原因？ – arg20

mmmm。我只是回答自己。主鍵不應該改變，用戶可以更改他的電子郵件。我想這是最大的原因。我應該刪除我的問題還是留給其他人看，以防萬一他們有這個疑問 – arg20

在此處留下它 - 下面顯示的答案將有助於其他人。 – AbdullahC

自帶的最大問題要記住的是用戶的電子郵件地址會隨着時間而改變。如果您設置了一個系統，其中的電子郵件地址是主鍵，那麼以後更改電子郵件地址是一個嚴重的問題 - 您必須將更改傳播到所有子表，這將要求所有外鍵約束都可延遲。

來源

2011-02-06 06:50:34

從

浪費空間的
分開。
連接中的性能問題。
索引中的空間浪費。

如果用戶可以選擇更改他的電子郵件ID，您將最終更改主鍵，這將是一個很大的努力/混亂。

來源

2011-02-06 06:52:54

一個表格可以有多個鍵。讓電子郵件成爲候選鍵。我喜歡想像PK競選美國總統。你有多個候選人，但只有1個可以當總統。

其他人說的很好。如果值更改，則不希望更新其他30個表。這有利於代理鍵（除了識別行之外沒有其他含義的鍵）。由於代理人沒有意義，你不必擔心他們的價值變化。通常他們是一個自動增量整數。

回到原點。您的代碼：

User selected = em.find(User.class, userEmail);

無論電子郵件是主鍵還是候選鍵，該代碼都應該完全有效。如果你的框架需要搜索主鍵，那麼你最好在現實世界中運行尖叫，因爲你搜索的不僅僅是PK。

來源

2011-02-06 13:56:16

它不要求你在主鍵上進行搜索，但它提供了一些非常簡單的方法，例如聲明。 – arg20

數據庫設計：電子郵件作爲表的ID

回答

相關問題