1

こんにちは（少なくともこのあたりでは）、

構築に問題がある多対多の関係スキーマがあります。主な問題は、私が主キーと外部キーのみを使用しており (物事を単純化するために varchar や enum を使用していない)、多対多の関係の数が予測できず、いつでも増加する可能性があることです。

さまざまな質問を見回しましたが、この問題に直接対処するものは見つかりませんでした。

問題を半分に分割したので、1 対多のスキーマが 2 つになりました。1つは解決されましたが、もう1つは私にフィットしています。

テーブル FOO が、単純な主キーを持つ標準的で退屈なテーブルであると仮定しましょう。それは一対多の関係にあるものです。

テーブル BAR は、FOO の複数のキーに関連付けることができます。関連するキーの数は事前にわかりません。

例：

  1. クエリから FOO は ID 3、4、5 を返します。
  2. BAR には、3、4、5 に関連する一意のキーが必要です (ただし、任意の数の ID が返される可能性があります)。

通常の結合テーブルは機能しません:

Table FOO_BAR
primary_key  |  foo_id  |  bar_id  |

FOO は 3 つの一意のキーを返すため、ここで bar_id は foo_id と 1 対 1 の関係にあります。

foo_ids 3、4、5 を単一の bar_id にマップできないため、2 つの結合テーブルを使用しても機能しないようです。

Table FOO_TO_BAR
primary_key  |  foo_id  |  bar_to_foo_id  |

Table BAR_TO_FOO
primary_key  |  foo_to_bar_id  |  bar_id  |

私は何を間違っていますか？私は物事を実際よりも複雑にしていますか? 問題にどのようにアプローチすればよいですか？助けてくれてありがとう。

4

1 に答える 1

1

FOO-BARは私には大丈夫に見えます。それがうまくいくと思わないのはなぜですか？

Say FOO = 1,2,3
Say BAR = A,B,C

Then an everything to everything relation will look like:
FOOBAR = 1, A; 1, B; 1, C; 2, A; 2, B; 2, C; 3, A; 3, B; 3, C

主キーを foo_id、bar_id にすることができます。本当に必要な場合を除き、別のキーは必要ありません。これにより、関係の重複を回避できます。

于 2012-09-22T09:36:17.403 に答える