-1

私は「間違い探し」マルチプレイヤーゲームを構築しています。

ゲームの仕様は次のとおりです。

  1. 各ゲームには最大10人のプレーヤーが参加できます。
  2. ユーザーは同じ画像を2回見ないようにする必要があります。
    （画像は4つの画像で構成されており、ユーザーはそれらの「違いを見つける」必要があります）。

私は何千枚、場合によっては何万枚もの写真から選ぶことができます。私が直面している問題は、ゲームプレーヤーの誰もまだ見たことがない画像を見つけるための、非常に非効率的でスケーラブルでない方法です。

私のデータベースにはusage table、次のフィールドを持つがあります。

  1. picture_id
  2. ユーザーID

私の現在の解決策は次のとおりです：

ユーザーがゲームに参加し、アプリはそのユーザーの使用状況テーブルに表示されない画像をデータベースから選択し、入力したユーザーごとに同じ機能を実行して、同じゲームの他のユーザーがすでに見た画像の値を追加します。

数万枚の写真のデータベースがあり、以前のゲームで使用量テーブルがすでにいっぱいになっていると、機能に時間がかかりすぎてゲームの流れが損なわれるのではないかと心配しています。

この方法はあまりスケーラブルではなく、多くのゲームがプレイされていることを意味する一定のトラフィックのかなり安定した流れを期待しています。

このロジックを改善する方法や、データベース構造を改善するための提案はありますか？

4

3 に答える 3

4

画像が使用されているかどうかを示すフィールドを (ユーザー/画像マッピングではなく) 画像テーブルに追加するだけです。その後、画像が使用されるたびにそのフラグを設定し、未使用の画像をすばやく識別するためにそのフィールドにインデックスを付けることができます。これは結果を hasBeenUsed() 関数に効果的にキャッシュしています。

一部の人々は、さまざまな理由で反対する可能性があり、そのような時期尚早の最適化は、非常に雑然とした非常に緊密に結合された構造につながる可能性があります。将来の保守性を損なう。

別の方法は、ユーザー/画像マッピング テーブルにすべての画像を含めることです。画像が使用されていない場合、関連する user_id は NULL のままになります。picture_id を最初に持つインデックスは、未使用の画像の識別を非常に迅速に行います。

しかし、何よりも、実際には、このランダムな選択を行う必要があるクエリに依存します。非常に多くの場合 (常にではありません)、データベース構造をまったく変更せずに、スケーラビリティの低いアルゴリズムをよりスケーラブルなアルゴリズムに置き換えることができます。ただし、クエリだけでなく、データに関するスキーマと動作情報 (制約、未使用の可能性が高いなど) を確認する必要があることを知る必要があります。

于 2011-12-15T13:42:36.830 に答える
3

これは時期尚早の最適化だと思います。

「数万」というと、人にとっては大したことのように聞こえますが、SQL エンジンにとってはほとんど何もありません。一部の実装では、50 ～ 60k 行未満のテーブルではインデックスを使用しません。これは、全体をメモリにロードするだけで高速になるためです。

ほとんどの実装で which short circuitを使用してクエリを作成することをお勧めEXISTSします。目的に応じて十分に高速である必要があります。

テーブル構造のサンプル コードやサンプル データを投稿していただければ、おそらくクエリを支援できますが、何も心配する必要はないと思います。

于 2011-12-15T13:22:36.270 に答える
0

10,000 枚の写真に対して 10 人のユーザー - 確率論を使用して、これらの 11 枚の写真をチェックした後、11 枚の写真を選択する必要があります (ランダムなアプローチを使用することをお勧めします)。

于 2011-12-15T13:20:42.153 に答える