0

ゲームと呼ばれるテーブルがあります(intによって一意)。

members というテーブルがあります（ユーザー名ごとに一意）。

各ゲームには、一度に最大 6 人のメンバーが参加できます。

ただし、メンバーはゲームを辞退することができますが、そのゲームに関与した記録を保持する必要があります。

次の個別の検索を行う必要があります。

  1. メンバーのアクティブなゲーム。

  2. メンバーの辞退ゲーム.

  3. ゲーム内で空きスロット (つまり、メンバーによって埋められていない場所) を検索します。

これに最適なテーブル構造は何でしょうか? カンマで区切られたすべての辞任したゲームのリストを含むメンバー用のテキスト フィールドを入力する必要がありますか? (これに関して私が見ることができる問題は、最終的にこれらのゲームのゲーム情報が必要になるため、これらのゲーム番号ごとにゲーム テーブルで個別の検索を行う必要があることです。これは、サーバーにとって非常に遅い作業のようです。 )

ゲームでは、現在のプレーヤーのユーザー名を含む 6 つのテキスト フィールド (SLOT1、SLOT2 など) が必要ですか? しかし、再び、辞任したメンバーはどうですか？

今私の質問の主要部分（上記のすべての混乱を引き起こしました）：

テーブルにインデックスを設定するにはどうすればよいですか?

検索を行うときは、SLOTS1 などを調べて、プレイヤーのユーザー名と一致するものがあるかどうかを確認します。したがって、これは 6 回の OR 検索です。これらのアクションのためにデータベースのインデックスを最適化するにはどうすればよいですか?

では、ゲームごとに退会メンバーをどうするかによって、インデックスをどうするか。

4

1 に答える 1

1

相互参照表を使用します。これは、 ( table への外部キー)、( gametableへの外部キー)、および(1 から 6 までの null 許容整数で、プレーヤーが占有している「座席」を示す 3 つの列を持つテーブルです。null は、プレーヤーは辞任しました）。(これについては、ゲームがどのように機能し、どのように組み合わせたいかによって、バリエーションが可能ですが、主なことは、 と への外部キーがあることです。)gamesuserusersplayer_numbergamesusers

上記の提案の主キーは、ご都合に合わせて(game, user, player_number)orになります。(user, game, player_number)

このような相互参照テーブルを検索する方が、6 つの列の OR 演算を含むクエリを実行するよりも (ユーザーにとってもデータベースにとっても) はるかに簡単です。

users@Jermin Bazazian によって提案されているように、テーブルの整数の主キーに切り替えることはおそらく良い考えです。

于 2012-04-30T18:01:05.343 に答える