1

私は問題に少し困惑しており、単純なものが欠けているのではないかと考えています。

私は3つのテーブルを持っています:

create table A (id serial primary key, name char(50));
create table B (id serial primary key, name char(50));
create table c (A int references A(id), B int references b(id));

以下を使用して、A & B 関係が繰り返されないようにします。

create index unique_a_b_in_c on c (A,B);

次に、休止状態を使用して、これらのファイルを Java オブジェクトにリバース エンジニアリングします。

ここまでは順調ですが、ここでやりたいことは、A の各インスタンスが B レコードの一意の組み合わせを持つようにすることです。(たとえば、B に 2 つのレコード (B1 と B2) がある場合、A レコードの可能な値は 4 つだけです。つまり、レコードなし、B1 レコード、B2 レコード、または B1 と B2 レコードです。 )

これまでの私の最善の試みは、レコードに属するタイプ B レコードに基づいて A に一意のハッシュコードを作成し、equals をオーバーライドして A の B レコードのコレクションの内容をチェックすることです。オブジェクトが等しい場合は A レコードを更新しますが、A レコードが新しい場合は保存できます。

明らかに、これは equals の重いプロセスであり、B のサイズが大きくなるにつれて、一致をチェックする際の処理時間が膨大になります。

私の現在の考えでは、この種の一意性を提供する試みを放棄し、重複を許可することです。ただし、A は構成元の B レコードの組み合わせによって実際に定義されるため、私の問題のコンテキストでは意味がありません。

これを解決する方法について考えている人はいますか?

どうもありがとう ！

4

1 に答える 1

1

「B」のグループを定義したら、それがすでに「A」として定義されているかどうかを確認する SELECT ステートメントを作成するのは簡単なことです。

SELECT A, count(*) as rows from c where B IN ( 'B1', 'B2' ... ) group by A

count(*) = IN 句の要素数である場合、B に一致する A が見つかりました。このステートメントは、特に B にインデックスが付けられている場合は比較的速く実行されます。

ただし、c が大きくなるにつれて遅くなります。追加してみることができます

HAVING count(*) = 2 (or whatever your count of the number of rows of B is)

ただし、HAVING は通常、最初のクエリの後にオプティマイザーによって実行されるため、おそらく高速化にはなりませんが、一致する場合は1行、一致しない場合は 0 行が返されます。

于 2012-07-23T23:45:44.173 に答える