我需要ID字段嗎？

Question

我有一個由GUID標識的對象。我將把它存儲在SQL DB中並設計表格。我應該使用guid作爲PK還是應該創建一個aditional ID字段？我永遠不會使用我知道的ID字段。這種情況有什麼好處？我看到它創造了什麼可能是他們的動機？

Answer 1

無論您還需要一個代理鍵取決於您的特定需求。加入GUIDS可能會比較慢，但是隻有您可以知道它們是否會影響系統的性能才能保證添加int鍵。 GUIDS也存在問題，以及數據如何物理存儲在磁盤上以及導致的性能問題。此外，由於PK在所有其他索引中，對PK使用GUID可以大大增加索引的大小。在提交使用GUID之前，您需要閱讀性能影響（這可能會因數據庫不同而不同）。

GUIDS不方便用戶使用。如果你在表中沒有一個好的自然鍵（例如人名錶不是唯一的，因此不能成爲一個自然鍵），那麼用戶可能需要有其他值來查詢（比如person_id ）。與客戶的6214304C-2C56-E011-BACB-00265582C0F2相比，普通員工對研究客戶1234的興趣會更高。'我也不認爲客戶想要致電客戶服務部門以尋求訂單號'6E14304C-2C56-E011- BACB-00265582C0F2' 。這不是一個不重要的考慮。

我不是說你不能使用GUID（你當然可以），但你需要知道你承諾什麼類型的問題，你可能有使用GUID的路徑之前。 Databasesa在有數百萬條記錄之後不容易改變，特別是對於設計來說至關重要的是PK。許多有關GUID的問題在你有很多記錄之前並不特別明顯。如果數據庫是永遠不會有這種級別的記錄的數據庫，那麼您可能永遠不會遇到這個問題，但是您需要在決定之前根據自己的預期數據庫使用情況考慮這些影響。

Answer 2

一種可能的情況是，當你從另一個數據庫/系統，它有它自己的GUID來的記錄。

Answer 3

瞭解我們需要了解應用程序的動機。

理由不有一個： GUID是所有你需要的訪問，檢索算法，檢索，胡說記錄

原因有一個： 信息數據中虛擬化。對於DB角度來說足夠的指導意義，可能不適合用戶的觀點。在其它附加ID字段可能是當在業務流程中考慮的主要領域，該領域的其他系統中使用的內容

Answer 4

這是很難回答權威性不知道更多關於您的業務需求。使用自然主鍵當然可能是合法的。在此擴展您的要求，或者在natural and synthetic primary keys上閱讀。

Answer 5

一個表至少應該有一個關鍵，但沒有理由創造一個又一個，如果你不會需要它。