商店「像哈希碼」以dB爲布爾類字段的描述以提高性能，並命名查詢短

Question

的背景，這個問題如下：

Hash code for expandable class (future proof)

不過，我應該提到我爲什麼想知道這一點。

我有一個有許多角色（布爾字段）的類。我不想做命名查詢（JPA）像

@NamedQuery(name= "searchUserWithRoles", query="SELECT u FROM User u WHERE u.role.admin = :admin AND u.role.printer = :printer AND ... .. . .+ 20 more booleans...) 

我的想法是讓在角色類中的所有領域，這降低了命名查詢到對應的哈希碼（或類似）：

@NamedQuery(name= "searchUserWithRoles", query="SELECT u FROM User u WHERE u.role.hashcode = :hashcode) 

我認爲（但我不確定）這會提高性能，但也使我的查詢非常短（我有更多的「角色」像我的用戶類中的字段）。

此外，當我更新角色類與更多角色字段我不需要更新命名的查詢。

這就是第一個問題的背景。

新的問題是：有什麼方法可以在Role類中生成一個「hashcode like」字段，該字段是對所有字段是true的描述（即使Role類用更多字段更新）？

在此先感謝

Answer 1

這聽起來像你並不需要一個「散列碼」 - 你只需要一個位掩碼。只要你有32個或更少的字段，你可以將它存儲在一個32位整數中。如果您有64個或更少的字段，則可以將其存儲在64位整數中。每個字段都會有一個專用的位 - 所以管理員可以是位0（值1），打印機可以是位1（值2），然後下一個字段是位2（值4）等。將這些值相加（實際上按位或）。

然後要查詢任何特定的組合，只需在數據和「掩碼」之間使用按位與，並僅設置相關位。因此，如果您想查找每個沒有打印機權限的管理員，請檢查value & 3 == 1。

請注意，所有這些都可能會干擾數據庫想要執行的任何索引，和無論如何，數據庫可能會以這種方式進行優化。你有沒有證據表明把它們作爲單獨的字段存儲 - 使你的表示更接近你的邏輯數據結構 - 實際上會導致一個問題？