1

私は (My)SQL を初めて使用し、テーブル設計のベスト プラクティスに関する適切な情報を見つけるのが困難でした。

私は配列を持っていると言って、チェス盤に一連の動きを保存したい$a = ['e4 e5', 'Nf3 Nc6', ...]

新しいので、私の最初のアイデアは、Game ID 用と Move 用の 2 つの列を持つ馬鹿げた小さなテーブルです。移動 (配列) はシリアル化され、文字列に格納されます。これは技術的にはうまくいくと思いますが、DB から潜在的に巨大なシリアル化された配列を読み書きすること (おそらくすべてのページの読み込み時) は、私には最適とは思えません。

ユーザー側で配列をキャッシュすることは、さまざまな理由で不可能である可能性があり、私が興味を持っていることではありません。

私は、その形式では完全に予測できないデータを最適に保存する方法を学ぶことに興味があります (たとえば、移動数は 1 から 1000 まで変化する可能性があります)。

4

5 に答える 5

3

ゲーム履歴全体を 1 つの行に保存するのではなく、ゲーム ID、移動、およびその移動のシーケンス番号を保存しないでください。

そうすれば、次のようなことを行うことで、特定のゲームの全履歴を取得できます

SELECT *
  FROM MovesTable
 WHERE gameID = id
 ORDER BY sequence
于 2013-01-14T02:50:39.617 に答える
1

一般に、次のいずれかの形式でテーブルを使用します。

  • GameId、MoveNumber、Move
  • GameId、MoveNumber、FromSquare、ToSquare

どちらを使用するかは、何に対してクエリを実行する必要があるか、およびデータがどのように表示されるかによって異なりますが、私は後者の提案に傾倒します.

これを、GameId と日付やプレイヤーなどのゲーム自体に関するデータを含む親テーブルと組み合わせることができます。

移動をブロック全体としてのみ消費する場合、つまり、常に移動チェーン全体が必要であり、個々の移動にクエリを実行しない場合は、提案どおりに文字列を保存できます。これには、返されるデータが 1 行しかなく、非常に高速であるという追加の利点があります。もちろん、欠点は、データを受信したら、データを逆シリアル化/解析する必要があることです。

于 2013-01-14T02:48:18.503 に答える
0

私は次のようなことをします

Game, MoveNumber, Move
----------------------
Game1, 1, e4 e5
Game1, 2, Nf3 Nc6
... 
Game2, 1, ....
于 2013-01-14T02:45:40.487 に答える
0

プレイヤー用、ゲーム用、ピース用、ムーブ用のテーブルがいくつか必要になります。

ゲームには、プレーヤー、色、日付や時刻などがあります

ピースは、それがどのように動くかを教えてくれます。ナイトかクイーンかなどです。

プレーヤーには、プレーヤーの名前などがあります。

移動には、ピース、ゲーム、プレーヤー、開始位置、および終了位置があります

これらのテーブルは、各テーブルの id フィールドに基づくリレーションシップによってリンクします。

于 2013-01-14T03:01:49.467 に答える
0

2 つのテーブルを試してください。

最初のテーブルには、各ゲームに関する情報が含まれています。誰がプレーヤーで、いつどこでプレーしたか、誰が勝ったか、および各ゲームに関連し、各ゲームをユニークにするその他の情報。

ゲーム

Game_id PK

Move_id FK

Black_name

ホワイトネーム

ゲーム_場所

試合日

ゲームの時間

勝者

2 番目のテーブルには、各ゲームのすべての動きが含まれています。これには、各動きに関連するすべての情報が含まれています: ピースが取られたか、他のプレイヤーがチェックされたか、これは通常の動きでしたか、キャスティングしましたかなど。

動きます

Move_id PK

Move_number

誰が移動したか

Piece_moved

Square_from

Square_to

Piece_taken

Move_type

Check_YorN

これで、Games テーブル (ゲーム) の各行が Moves テーブルの多くの行 (移動) に結合されます。

于 2013-01-16T17:08:27.493 に答える