對主鍵使用按位標誌？

我正在設計一個數據庫，並且正在考慮需要一對多的關係。傳統上我做了普通的PK（作爲GUID）並建立了關係，但是我想知道如果這麼做，爲什麼不使用按位標誌作爲PK。對主鍵使用按位標誌？

這種關係會丟失，但數據本身會描述關係。

示例 - 我有一張表和一組用戶表。用戶可以有1個或更多的組：

+------------------------+ 
| Groups     | 
+------------------------+ 
| PK  | Display Name | 
+---------+--------------+ 
| 1  | Group A  | 
| 2  | Group B  | 
| 4  | Group C  | 
+---------+--------------+ 

+------------------------+ 
| Users     | 
+------------------------+ 
| Name | Groups  | 
+---------+--------------+ 
| Fred | 1   | // Fred is only in Group A 
| Jim  | 3   | // Jim is in Groups A & B 
| Sam  | 7   | // Sam is in all Groups 
+---------+--------------+

有關此設計的想法，意見和建議嗎？

來源

2009-07-09 Robert MacLean

不好主意......該指數如何工作？它將不得不掃描並對每個值進行計算...

假設您想知道組X中的所有用戶...您必須在每一行上運行函數以確定是否他們在那個組裏，而不是僅僅做一個很快的索引來尋找你的答案。

編輯：簡單地...寫一個查詢，使用您的表上的索引查找組B中的所有用戶...無論如何，你會做一個計算，這將迫使它遲到 - 過濾掃描

來源

2009-07-09 16:15:58

不錯的主意，不知道它將如何從關係數據庫中獲益。我認爲如果你使用SQL，你幾乎不得不使用標準密鑰，否則你有昂貴的存儲空間有什麼意義？

也許它會更適合基於文件的存儲，其中每個表位於不同的文件中。或者，將它作爲附加列，但不要在其上放置主鍵。

P.S. 如果兩個用戶在同一組中，它不會崩潰嗎？

Ryan

來源

2009-07-09 12:29:59

組成員身份不是PK，所以它應該可以，如果他們在同一組。 – GalacticCowboy 2009-07-09 13:19:48

我不鼓勵使用這樣的位標誌。一方面，您已經打破了輕鬆加入這些表的能力，因此確定組成員將需要更長的時間，b）更加困難，並且c）可能涉及更多的全表掃描或至少索引掃描。

來源

2009-07-09 12:31:42 GalacticCowboy

你很快就會用完數字。如果你有64個組，你已經使用了64位。我不寒而慄，想想如果你有一百萬組會發生什麼事。

與此相關的另一個問題是，如果您刪除了一個組，那麼您已經丟失了一點。您稍後可以重複使用該位，但這可能不是您想要的方式。

來源

2009-07-09 12:31:59 rein

不好IMO。這是典型的多對多關係。如果PK是32位，則一個用戶最多可以在32個組中。爲什麼要限制設計？

// Sam在所有組中。例如：

比方說你修改設計，並使PK 4位全部排在第3位。現在是Sam在「所有組」還是僅在組0-7中？

什麼是收益？

你會如何編寫查詢（連接）？我認爲你會在這個設計上遇到問題。

來源

2009-07-09 12:37:42

我見過最近用作主鍵的GUID，我認爲這是一個可怕的想法。 GUID代表「Globally Unique ID」，也就是說，它是一個標識符，它的複製機會是，在他的OLE書中誤導Brockmeyer「就像一堆原子在空中一起衝到一起形成一個小核桃」。

如果你確實需要全局唯一的東西，那麼有很好的理由使用GUID，但是大多數數據庫鍵只需要相對於有問題的數據庫是唯一的。在這種情況下，順序生成的整數密鑰通常就足夠了，並且在資源方面消耗的很少。實際上，無論序列ID還是GUID都沒有任何內在含義，所以如果可以使用真正能夠真正將所討論的對象識別爲主鍵的項目（如果可以的話），那麼它確實會更好（儘管有一派思想說所有項目應該有一個與內容無關的密鑰，如序列甚至GUID）。

位域有幾個負責人作爲主鍵。如前所述，你可能會決定你需要額外的位。你可能會碰到碰撞。數據庫往往在按位功能方面很差，即便如此也不可移植。最後，您選擇的數據庫的索引算法可能無法很好地優化位集密鑰。

來源

2009-07-09 12:47:04

作爲PK的GUID的一個優勢是客戶端代碼可以生成一個密鑰（具有合理的唯一性期望），而不是返回到數據庫以找出密鑰將會是什麼。如果您正在進行斷開編輯，這是特別有利的。另一方面，你一定要小心照顧他們。例如，不要將GUID作爲表上的聚集索引/鍵，因爲數據的順序基本上是隨機的，大多數插入將落在表的中間某處並要求移動數據。 – GalacticCowboy 2009-07-09 13:25:08

對主鍵使用按位標誌？

回答

相關問題