0

状況に大きく依存するデータを含むテーブルがあるとします。

例としては、プレイヤーが勝つための選択を行うゲームのコレクションがあります。この選択は保存する必要がありますが、ゲームは異なるため、あるゲームの選択が別のゲームの選択に実際には適合しません。

一般に、すべてのケースを処理するのに十分な幅のテーブルを作成し、エントリごとに一部の (ただし異なる) 部分を未使用のままにしておく方がよいでしょうか、それともケースごとに特別なテーブルを作成する必要がありますか?

それとも、他にもっと良いテクニックがありますか？

4

3 に答える 3

1

私があなたを正しく理解していれば、3つのテーブルを必要とするm：n関係を望んでいるようです：

CREATE TABLE game
    (
    id int PRIMARY KEY,
    game nchar(x)
    )

CREATE TABLE solution
    (
    id int PRIMARY KEY,
    solution nchar(x)
    )

CREATE TABLE game_solution
    (
    id int PRIMARY KEY,
    id_game int NULL REFERENCES game( id),
    id_solution int NULL REFERENCES solution( id)
    )
于 2013-04-03T20:17:42.433 に答える
0

@ラース：あなたの質問を読み直しました。

短くするために：

  1. 最大のパフォーマンスが必要な場合は、多くの新しいテーブルを作成する必要がある場合でも、完全に構造化しておいてください。

  2. 柔軟性が必要な場合、たとえば結果構造がまだわかっていない将来のゲームの結果を保存する場合、パフォーマンスを考慮せずに、バイナリ値またはソリューションを含むファイルへのリンクを保存します。

  3. 柔軟性とパフォーマンスの向上が必要で、最も一般的なソリューション タイプの構造を既に知っている場合は、これらを構造化テーブルに保存し、その他すべての予測不可能な (将来の) ソリューションをバイナリまたはファイルへのリンクとして保存します。

  4. 簡単にしたい場合は、ポイント 1 または 2 を使用してください。ポイント 3 はプログラムに多くの複雑さを追加します。

これが適切な答えであることを願っています。誰かがより良い提案を持っているなら、私は興味があります!

于 2015-01-05T23:20:30.710 に答える
0

あなたの質問は一般的なものなので、短い答えは次のとおりです。より長いものは次のとおりです。「広い」テーブルは、あまり差のないゲームが数個しかない場合に簡単な解決策です。私がその解決策を採用する場合もありますが、一般的にはそうではありません。

私のアドバイスは次のとおりです。すべての選択/選択に共通するものは何かを自問してください。そのデータは一般テーブルに移動する必要があります。特定のゲームに固有のデータは、ゲームごとに別の関連テーブルに移動する必要があります。

プログラマーとしてのバックグラウンドがどのようなものかわかりません。ただし、OO プログラミングに精通している場合は、クラス階層を SQL データベースにマップする方法についてググってください。

于 2013-04-03T20:34:43.860 に答える