8

テーブルがあるパーミッションモデルを使用していますuser_permissions。このテーブルは、特定のbigintを持つ1つ以上の列を保持します。各10進数のビットを使用して、特定のアクセス許可ルールと比較します（ビットの場所はアクセス許可ルールになり、値はルールactiveまたはの条件になりますnot active）。

このアプローチの問題は、bigintなどの数値を使用するときに機能するビット数が限られていることです。

クロスデータベース環境で機能する、この場合に使用できる最適な列タイプは何ですか？

タグは私が目指している技術を表しているので、それらの技術に関連する他の解決策はありがたいです。

@Lobアノテーションを使用して大きなデータを格納することを考えていましたが、それがベストプラクティスですか？

更新：user_permissionテーブルは、1：1の関係でユーザーを拡張し、bin_create、bin_read、bin_update、bin_deleteなどのbigintフィールドを持ち、バイナリデータを10進数として保持します。

質問を明確にするために：ビット演算子を使用してアクセス許可を比較することを検討しています。したがって、アクセス許可値が10（1010）のユーザーがいて、アクションに13（1101）が必要であると仮定します。したがって、10＆13 == 8（1000）->ユーザーには、アクションに必要なアクセス許可に一致する1つのアクセス許可があるため、許可または拒否できます（どちらを定義するかはアプリケーションルール次第です）。しかし、このアプローチでは、作業するビット数が限られています（たとえば、検討するアクセス許可を増やすと、数も増えます）。最大bigint値は〜9223372036854775807であり、これにより、フィールドごとに〜60ブロックとパーミッションの可能性があるバイナリ111111111111111111111111111111111111111111111111111111111111111が得られます。

4

3 に答える 3

1

気になるフィールドに収めることができるデータの量であれば、その数値をvarcharとして保存してみませんか？私の知る限り、ほとんどすべてのデータベースで、少なくともvarchar（255）まで使用できます。数値に255桁以上が必要な場合は、基数64でエンコードして、さらに絞り込むことができます。私の暗算が正しければ、255文字*1文字あたり6ビット=1530の異なるビットを使用できます。それ以上が必要な場合は、パーミッションモデルが少し過剰であることをお勧めします。

これは、データベース内の小さなスペースにデータを詰め込もうとしていることを前提としています。あなたの質問は、あなたが何を解決しようとしているのかについて完全に明確ではありません。スペクトルのもう一方の端では、ビットを解凍して、各ビットを独自のフィールドまたは独自の行に保存できます。たとえば、user_permissionsは、userとpermissionの2つの列を持つテーブルであり、各行は1人のユーザーに付与された1つのpermissionです。

于 2013-02-15T05:38:17.200 に答える
1

データを最適な方法で保存する場合は、最適化するターゲットに名前を付ける必要があります。

これはMySQLに最適なソリューションです（を定義することによりBINARY(32)）。お気に入りのデータベースで同様のことを試すことができます。

@Column(columnDefinition = "BINARY(32)", length = 32, nullable = false)
private byte[] bits;

一部のJPAプロバイダーおよびデータベースでは、列定義がで終わる場合がありますLob。Lobaの読み取りは外部（非常に高価な）操作であるため、これは最善の解決策ではありません。プロバイダーまたはデータベースのいずれかを変更してみてください（純粋なJPAを使用している場合は、それを試すことができます）。

sを置き換えるためのオプションLobは、たとえば数値列です（たとえば、64ビット幅の4列などを使用できます）。優れたソリューションが必要な場合は、これらのコンテナ列を@Embeddedメインクラスに含めることもできます。しかし、それはすべてデータベースに依存します。

このようにして、変換や追加の計算を行わずに256ビット（32バイト）を使用でき、必要に応じて範囲を拡張することができます。ただし、列の定義を変更するときは注意が必要です。

于 2013-02-18T23:33:56.947 に答える
0

2つの異なるアプローチがあります。

1）かなりのデータモデル

1つの行（この例ではユーザー）に値（ここでは1ビットまたはブール値のユーザー権限）を含めることができます。この場合、可能な値の数がわかりません。つまり、値の数は基本的に無制限です。これを処理するSQLの通常のアプローチは、子テーブルです。

テーブル（およびマッピング/アノテーション用のJavaクラス）UserPermissionを作成します。これには、外部キーとしてのユーザーID、アクセス許可ID、およびブール値が含まれます。ユーザーIDと権限IDは、このテーブルの一意のキーです（必要に応じて、IDを別の主キーとして追加できます）。監査が必要な場合は、許可を与えたユーザー、これが行われた日付などの列を追加することもできますが、これは必須ではありません。

より美しくしたい場合は、テーブル（およびJavaクラス）のパーミッションも作成します。このパーミッションには、パーミッションID、パーミッションの名前、およびその他の情報が含まれています。

このソリューションでは、整数のビットを使用したアイデアよりも多くのデータベーススペースが必要ですが、データベース内の他のデータと比較してユーザー数が少ないため、余分な量は関係ありません。

2）迅速な解決策：

アクセス許可はそれほど重要ではなく、整数が短くなる可能性があるため、余分なテーブルを使用するソリューションで多くのオーバーヘッドが必要な場合は、JavaタイプBigInteger（タイプはビット操作を許可します）を使用して、@Columnアノテーションを付けてマップできます。NUMBERまたはDECIMALデータベース内。

データベースのサイズにNUMBERも制限があることに注意してください（たとえば、Oracleでは最大10 ^ 40が許可されます）。これが問題になる可能性がある場合は、解決策1）を使用する必要があります。

ソリューション2）のもう1つの欠点は、アクセス許可にインデックスを使用できないことです。（特定の権限セットを持つすべてのユーザーの選択は、インデックスを超えることはありません。）

私はいつも解決策を使います1）。

于 2013-02-15T08:01:32.513 に答える