找到一個自然的主鍵有什麼好處

我的問題或多或少與this one相反：爲什麼有人想要在使用序列作爲代理時更容易地找到關係中的自然主鍵。找到一個自然的主鍵有什麼好處

BradC在his answer中提到相關問題，即選擇主鍵的標準是唯一性，不可約性，簡單性，穩定性和熟悉性。在我看來，使用序列會犧牲最後一個標準，以便爲前四個提供最佳解決方案。

如果我認爲這些標準是正確的，我可以將我的問題重新定義爲：在哪種情況下，人們會認爲通過尋找一種獨特的，不可簡化的，簡單而穩定的鑰匙來使人的生活複雜化也是有利的。

來源

2013-10-02 scozy

我很確定「熟悉」是爲了與你所說的完全相反，即*不會讓人的生活複雜化 – bengoesboom

這個問題看起來是基於一個非常基本的誤解，即表只需要一個鍵，任何鍵都可以。錯誤和錯誤！更明智的是要問：「鑑於數據庫設計中自然鍵的基本重要性，在什麼情況下，人們認爲通過添加代理鍵來使人的生活複雜化是有利的？」 – sqlvogel

看看這個[link]（http://stackoverflow.com/tags/surrogate-key/info）關於這個話題的更多思考。 –

您通常需要確定數據上的唯一鍵是什麼，因爲您仍然需要能夠確保數據不重複。

合成密鑰的優勢在於它允許將來可修改唯一的自然密鑰的值，並且不需要更新子記錄。

因此，您並不是真的通過使用合成主鍵來跳過設計的「確定關鍵」部分，而是讓自己遠離了值改變的可能性。

來源

2013-10-02 17:07:41

這聽起來很不錯。因此，在一個完美的世界中，我們既有主鍵，又有可能對屬性集合應用「唯一」約束？ – scozy

@scozy在來自不屬於您的管轄區域的密鑰的情況下（如SSN），甚至很難（因此_silly_）對它們強制實施UNIQUE約束。從邏輯上講，它們是獨一無二的，在完美的世界裏它們應該是獨一無二的。但在現實生活中卻並非如此，因爲數據來源並不完美。當幾乎候選鍵的多個（時間戳）版本可以共存時，這個問題變得更糟。（有關詳細信息，請參閱：google for「數據保險庫」） – wildplasser

如果您確實選擇了代理鍵，您仍然必須爲固有數據約束設置UNIQUE鍵，否則您的表中會有垃圾。那麼爲什麼首先使用代理鍵呢？如果您確實需要開放更改數據的可能性，則可以隨時添加自動增量密鑰。 – DanMan

爲了從查找表中獲得有意義的值而不做不必要的連接。

示例案例：garments引用顏色查找表，該查找表具有自動增量主鍵。獲取顏色的名稱需要加入：

SELECT c.color 
FROM garments g 
JOIN colors c USING (color_id);

簡單的例子：在colors.color本身是表的主鍵，因此它在引用它的任何表的外鍵列。

SELECT g.color 
FROM garments g

來源

2013-10-02 16:27:18

這是一個有趣的例子。這種情況在我的實踐中從未發生過，但我並不專注於數據庫。它是否經常發生在你的職業經歷中？ – scozy

使用查找表？是的，所有的時間。在查找表中使用自然鍵？是的，所有的時間。 –

答案是數據的完整性。數據庫之外的業務領域中的實體實例根據定義是可識別的事情。如果你沒有給他們外部的真實世界標識符在數據庫，那麼該數據庫幾乎沒有正確建模現實的機會。

自然鍵[1]是確保數據庫中的事實可以用您試圖建模的現實中的實際事物來識別。它們是用戶在對數據庫中的數據進行操作和更新時所依賴的手段。執行這些密鑰的約束是業務規則的實現。如果您的數據庫準確地爲業務領域建模，那麼自然鍵不僅是可取的，而且也是必不可少的。如果你懷疑那麼你沒有做足夠的業務分析。只要問問你的客戶他們認爲他們的業務如何運作，如果他們留在屏幕上充滿重複的數據！

[1]我建議稱他們業務鍵或域鍵而不是自然鍵。即使它們意味着完全相同的東西，那些更合適和更少超載的條款。

來源

2013-10-02 18:59:46 sqlvogel

找到一個自然的主鍵有什麼好處

回答

相關問題