的Varchar，相較於代理主鍵（不是一個自然的鍵）數字

什麼是你認爲的代理主鍵，數字或VARCHAR更好的選擇？在我們的例子中，我們使用varchar2（15），所以不是一個很大的列？的Varchar，相較於代理主鍵（不是一個自然的鍵）數字

我不會重開關於自然VS代理鍵的使用線程。我們使用自動生成的主鍵列（又名代理鍵）和用於業務密鑰的用戶密鑰（又名自然鍵）。我們沒有擔心編寫SQL將不得不加入許多表。在主鍵中使用Varchar，我們可以使用前綴後跟序列生成的數字轉換爲字符串。這允許基於該前綴值進行分區。

謝謝。 rimetnac

來源

2014-12-09 rimetnac

嗯 - 你的問題似乎回答它自我，因爲你實際上計劃在你的鑰匙有非數字？ – 2014-12-09 11:50:11

數字非常適合在分區中使用，否？如果它們是按順序給予的，那就是，如果是隨機給予的話。 – tvCa 2014-12-09 12:03:26

使用varchar2型主鍵時可能面臨的一個威脅是，使用nls_comp = linguistic時，由於自動內部varchar2-column-predicates修改，Oracle優化器將突然停止使用通過主鍵列進行索引查找。我相信在某些情況下，它也可能會停止分區修剪。當然，它可以通過編程來解決，但它仍然是您項目計劃之上的一些工作。

第二個威脅是潛在的不正確的查詢成本算法。我不記得這是多麼不正確它，你必須查找例如Jonathan Lewis的「基於成本的Oracle基礎知識」一書，請閱讀相關部分，並針對您使用的Oracle版本進行自己的研究。

來源

2014-12-09 11:57:51 nop77svk

-1

如果沒有爲VARCHAR沒有獨特的自然鍵，使用自動增量INT。

來源

2014-12-09 12:00:08 i486

在Oracle，VARCHAR值需要比等於NUMBER值約兩倍更多的空間。這就是爲什麼VARCHAR主鍵意味着雙主鍵索引，更差的索引搜索，更糟糕的緩衝區緩存利用率等等。我懷疑它是否好設計，特別是如果數據大到足以進行分區。

來源

2014-12-09 16:45:57

你正在造成你描述的設計不必要的問題。首先，你有一個唯一標識每個元組的自然鍵。但是您已選擇使用代理鍵作爲主鍵。目前爲止沒有問題。現在介紹一個未命名的屬性，它將元組分成邏輯分組。這也沒關係。但是你爲什麼要把它與PK結合呢？那得到了什麼？通過保持這個屬性獨立，你想要的分組也可以被完成（並且在許多方面更好）。

在此屬性與PK相結合，它失去了它的身份這麼說。這就像將每個學生的StudentID與大學數據庫中的專業名稱相結合。根據專業分組有多種理由，但現在沒有特定的「主要」字段，而是「Major_SID」汞合金。立即顯而易見的一個問題是切換專業。更新「主」字段非常簡單。更新連接字符串的「主要」部分而保持其他部分不變更難。

這種額外的問題並非不可克服，並很可能是值得的，如果好處是更大的。這種方法是否提供了這種壓倒一切的好處？它是否提供任何好處？

減去這樣的好處，我的建議是保持分組屬性分開。這也將保持代理鍵對於元組的內容是匿名的。以及保持數字，這比文本更容易排序。

來源

2014-12-09 23:33:00 TommCatt

的Varchar，相較於代理主鍵（不是一個自然的鍵）數字

回答

相關問題