0

エンティティに関連する一連のフラグをデータベースに保存する必要があります。Flagsこれらはバイナリ情報 (オン/オフ) ではなく、定義される一連のコードであるため、最適な言葉ではない可能性があります。

通常、各情報 (各フラグ値など) を個別の列に格納しますが、列マッピングの劇的な増加を防ぐために、属性ごとに 1 列とは異なるデータ構造にそのような情報を格納する機会を探っています。 . 各フラグはエンティティの各属性に対して有効であるため、本質的に多数の列を必要とする大規模なエンティティの場合、列の総数が 2n になる可能性があることを理解できます。

最終的に、これらのコードは位置文字列にマップできます。

私は次のようなことを考えています:ではなく、次のよう02Aに解釈さdec 42れます:

  • 位置 1 のフラグ 0 (または、必要に応じてゼロ...)
  • 位置 2 のフラグ 2
  • ポジション 3 のフラグ A

このようにフォーマットされたデータは、高水準プログラミング言語で簡単に処理できます。PL/SQL は問題の範囲外であり、これらの値はすべて Java で処理されるはずだからです。

今、本当の問題

私の仕様の 1 つは、検索を最適化することです。特定の位置で特定のフラグ (または特別なフラグ) を示すエンティティを探す方法 (たとえば、効率的な方法) を見つける必要がありました0。

通常、SQL では、RDBMS 固有の部分文字列関数を指定すると、次のようになります。

SELECT * FROM ENTITIES WHERE SUBSTRING(FLAGS,{POSITION},1) = {VALUE};

これは機能しますが、部分文字列にマップされたセカンダリ インデックスの作成をサポートしている Oracle 以外のすべてのプラットフォームで少し遅いかもしれません。

ただし、私のソリューションは、Hibernate のおかげで MySQL、Oracle、SQL Server、および DB2 で動作する必要があります。

そのような設計を考えると、私が見逃している、おそらくクロスプラットフォームのインデックス作成戦略はありますか?

4

3 に答える 3

0

そのようなフラグを格納するためのデータベースに依存しない合理的な方法が必要な場合は、一般的な SQL データ型を使用してください。バイナリ フラグの場合は、bitまたはを使用できますboolean(これはデータベースによって異なります)。その他のフラグについては、tinyintまたはを使用できますsmallint。

少しいじっても移植性はありません。少なくとも、データから特定のビットを抽出するために使用される関数は、データベースによって異なります。

第 2 に、パフォーマンスが問題になる場合は、完全なテーブル スキャンを回避するためにインデックスを作成する必要がある場合があります。通常の SQL データ型でインデックスを作成できます (ただし、一部のデータベースではビットでのインデックスが許可されない場合があります)。

あなたは過度に賢くしようとしているように聞こえます。最初に、適切なデータ構造を使用してアプリケーションを動作させる必要があります。次に、パフォーマンスの問題がどこにあるかを理解し、それらの修正に取り組むことができます。

于 2014-01-15T12:12:59.770 に答える