4

次のエンティティを持つ投票システムをモデル化しています。

  • カテゴリー
  • 候補者
  • 段階

名前が示すように、カテゴリと候補者をそれぞれのテーブルに格納します。投票には 2 つのフェーズがあります。第 1 段階では、各カテゴリに 8 名がノミネートされます。最も投票数の多かった 4 人の候補者が第 2 段階 (および最終段階) に進みます。

これまでのところ、私はこの構造を持っています（簡略化）

category
    id      PK
    name

nominee
    id      PK
    name

phase
    id      PK
    name

私の問題は、投票部分をモデル化する方法です。2つのオプションがあると思いますが、どちらが優れているか、それぞれの長所と短所はわかりません。

オプション 1:複合 3 列の主キーを持つ category_nominee テーブルを持つ (ここでの「正規の」PK はこれら 3 つのフィールドによって形成されていると確信しています。パフォーマンスへの影響についてはわかりません。mysql を使用しています)

category_nominee
    category_id         PK
    nominee_id          PK
    phase_id            PK

これについて私が気に入らないのは、category_nominee に単一の識別子がないため、votes テーブルから category_nominee を参照するには、これらの 3 つの列を再度使用する必要があることです。したがって、投票テーブルでは、3 つの列を繰り返す必要があります。

vote
    id
    category_id         FK
    nominee_id          FK 
    phase_id            FK

さらに、category_id が category.id または category_nominee.category_id を指す必要があるかどうかはわかりません (私は後者に傾いています)。

オプション 2: category_nominee に自動インクリメントされた id 列を作成し、category_id、nominee_id、および phase_id を複合一意キーにします。

category_nominee
    id
    category_id         Unique
    nominee_id          Unique
    phase_id            Unique

vote
    id                  PK
    category_nominee_id FK

これにより、category_nominee レコードの参照が簡単になり、繰り返しが回避されます。投票には、category_nominee よりもはるかに多くの記録があると予想しています。それでも、どちらのオプションがより便利かはわかりません。

オプション 1 の SQL Fiddle

オプション 2 の SQL Fiddle

4

1 に答える 1

1

データのモデリングについて学んだことから、オプション 1 が適切なオプションです。おそらくこれが外部キーの存在の理由です。オプション 2 を見たことがない。

ただし、オプション 1 では、category_nominee と vote が重複しています。次のようなものを実装します。

category
    id      PK
    name

nominee
    id      PK
    name

phase
    id      PK
    name

vote
    (category_id         FK
     nominee_id          FK 
     phase_id            FK) PK
    //others fields required or not

すべてのテーブルで一意の列名が必要な場合は、(category_nominee.)category_id フィールドの名前を変更することを妨げるものは何もありません。この列を元の列に外部キーとしてリンクするだけです。

于 2016-11-14T14:16:37.577 に答える