0

この質問の背景は次のとおりです。

展開可能なクラスのハッシュ コード (将来の証明)

ただし、なぜこれを知りたいのかについて言及する必要があります。

多くの役割（ブールフィールド）を持つクラスがあります。のような名前付きクエリ (JPA) を作成したくない

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

私の考えは、名前付きクエリを次のように削減する Role クラスのすべてのフィールドのハッシュコード (または同様のもの) を作成することでした。

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

これによりパフォーマンスが向上するだけでなく、クエリが非常に短くなると思います（ユーザークラスのフィールドのような「ロール」があります）。

また、Role クラスをさらに多くのロール フィールドで更新するときに、名前付きクエリを更新する必要はありません。

それが最初の質問の背景です。

新しい質問は次のとおりです。Role クラスに、真のすべてのフィールドの説明である「ハッシュコードのような」フィールドを生成する方法はありますか (Role クラスがより多くのフィールドで更新されたとしても)?

前もって感謝します

4

1 に答える 1

2

「ハッシュコード」は必要ないように思えます-ビットマスクが必要なだけです。32 個以下のフィールドがある限り、これを 32 ビット整数に格納できます。フィールドが 64 個以下の場合は、これを 64 ビット整数に格納できます。

各フィールドには専用のビットが 1 つあり、管理者はビット 0 (値 1)、プリンターはビット 1 (値 2)、次のフィールドはビット 2 (値 4) などになります。値を足し合わせるだけです。 (事実上、ビットごとの OR)。

次に、特定の組み合わせを照会するには、データと関連するビットのみが設定された「マスク」との間でビットごとの AND を使用します。したがって、プリンタ権限を持っていないすべての管理者を見つけたい場合は、value & 3 == 1.

これらはすべて、データベースが実行したいインデックス作成を妨げる可能性があり、データベースはこの種の方法で最適化される可能性があることに注意してください。それらを別々のフィールドとして保存すること、つまり表現を論理データ構造に近づけることが実際に問題を引き起こすという証拠はありますか?

于 2012-08-04T08:37:54.117 に答える