0

すべてのマジック ザ ギャザリング カードのデータベースを作成しています... カード テーブルは次のようになります。

  • カードID
  • 名前
  • 文章
  • レアリティID
  • 色ID
  • エディションID
  • 他の列...

同じカードが複数のエディションに登場する可能性があり、いくつかの特殊なケースでは、別のエディションでは異なるレアリティになります。

その方法を私が知っている唯一の方法は、カードが登場するエディションごとに 1 つの新しいカード エントリを作成することです。しかし、同じカードが 10 以上のエディションに変更なしで表示される場合があり (少なくとも、このデータベースに関連するものは除きます)、不要なエントリを多数作成することになります。

より良い解決策はありますか？

4

2 に答える 2

1

コメントでのフィードバックに進みますが、これは私が推奨するものです (まだ変更を見逃す可能性がありますが、公正なスタートだと思います)。ドメイン モデルのすべてをキャプチャするようにしてください。後でデータを変更するのは簡単です..それがあれば。

カード |-これらはすべてのエディションのカードに共通です*
 CardId、CardName、DeckColor、..
 |-PK-| |-キーの可能性は? -|

エディション
 EditionId、EditionName、ReleaseDate、..
 |-PK -| |-キー? -|

CardEditions |-これらはカード/エディションごとに一意です
 CardId、EditionId、レアリティ、ルール、..
 |-PK -|
 |-FK-| |-FK -|

(*Bill Karwin は多色のカードがあることを指摘しています、arg! その要件を把握するには、CardEditions のように CardsColors 関係をフロートします。色がエディション間で同様に変化する場合、私は泣きたいだけです..)

上に単純なスキーマを示しました (おそらく完全には正規化されていません)。ただし、それを処理するにはいくつかの異なる方法があるため、「Slowing Changing Data」を参照してください。

コメントの更新:

特定のエディションのカードを見つける方法、たとえばカード名とエディション名がわかっているとします。

SELECT * FROM Cards c
JOIN CardEditions ed
  on ed.cardId = c.cardId
JOIN Edition e
  on e.editionId = ed.editionId
WHERE c.cardName = 'Some Awesome Card'
AND e.editionName = 'Ultimate'

CardName と EditionName が主キー (PK) として使用され、対応する FK で (サロゲート CardId/EditionId の代わりに) 使用された場合、結合を完全に回避できた可能性があることに注意してください。どちらのアプローチが優れているかについては、大きな議論があります。クエリをよりシンプルに保ちたいので、結合テーブル (CardEditions など) を除いて複合 PK を避けるために代理キーを使用します。ただし、これでも EditionId 代理キーを使用/保持する必要があります..

可能性のあるキー (または「キー?」) は、このフィールドもキーとして扱う必要があると思われることを意味し、一意の制約 (および場合によってはインデックス) を適用する必要があります。リレーションシップには複数のキーを含めることができます。キーは、レコードを一意に識別するために必要な一連の列です。主キーは、この目的で通常使用される「選択された」キーです。

このモデルは完全に正規化されていないことに注意してください。1 つのリレーションに複数のキーが存在するという事実そのものです。ただし、代理キーと一貫性を保ち、2 次制約を定義することが最も生産的であることがわかりました。これは、私がレコードをモデルを駆動するエンティティとして扱いたいという事実の結果でもあります。

于 2013-07-02T00:24:57.383 に答える
0

MySQL はリレーショナルデータベースであり、その機能を適切に活用するには、オブジェクトを相互に関連付ける必要があることを理解してください。したがって、最初に行う必要があるのは、さまざまなオブジェクトが何であるか、およびそれらが互いにどのように関連している可能性があるかを理解することです. あなたの説明から、カードとエディションの少なくとも 2 つのオブジェクトについて言及されています。

cardsつまり、最初に と の 2 つのテーブルが必要だと思いますが、editionsそれらはどのように関連しているのでしょうか。1 対多の関係がある場合 (つまり、各エディションは多くのカードを持つことができますが、各カードは 1 つのエディションのみに属します)、エディション ID のカードに外部キーを持つことができます。しかし、この場合、多対多の関係があるようです。これは伝統的に、関係を説明するために 3 番目のテーブルを追加することによって実現されます。したがって、この場合cards_to_editions、カード ID とエディション ID の 2 つの列だけで構成されるテーブルを追加できます。これらは両方とも、それぞれのテーブルへの外部キー キーであり、テーブルの複合主キーを形成します。

関係自体に固有のプロパティがある場合は、cards_to_editions テーブルにプロパティを追加することもできます (この場合は「レアリティ」のようです)。

于 2013-07-02T00:30:41.697 に答える