0

私は、各ユーザーが毎日フットボールの試合に複数回賭けることができるメンバー ウェブサイトを持っています。アイデアは、毎日のポイントを合計して計算し、グラフに表示することです (Google チャート API を使用)。これまでのところすべて順調です。ユーザーごとに毎日新しいポイントが計算され、過去のポイントと一緒にグラフに表示されます。ユーザーが過去の結果を曲線またはグラフで確認できるようにするため。私の唯一の推測は、ID - ユーザー名 - ポイント - ラウンドでテーブルを作成することです。テーブルとクエリの構成が不十分なために、データベースに問題が発生することは望ましくありません。

私の質問は次のとおりです。データベースでこれをどのように設定すればよいですか?

これは今の私のテーブルです：

表 -> メンバー
ID
名
姓
ユーザー名
パスワード

（私の架空のテーブル）。

TABLE -> MEMBERS_POINTS
ID
ユーザー名
ポイント
ラウンド

そこで、必要なラウンドからユーザー ポイントを取得するクエリを設定しました。これは良い方法ですか？これによりデータベースの速度が低下しますか? すべてのユーザーは 30 ラウンドをプレイし、数人のユーザーの場合、テーブルにはおそらく数千行が含まれます。

ここで投稿を見つけますが、答えがなく、いくつかの異なるアイデアがあります。

編集

登録するすべてのユーザーが一度に 60 の賭けすべてを行う必要があるメンバー サイトであり、60 の賭けは 30 日間にわたって分割されます (これをラウンドと呼びます)。各ラウンドは 2 ベットで構成され、最大 6 ポイントです。合計スコアは、毎日の勝者とともに、合計でリーダーと一緒に表示されます。各ユーザーは、自分の過去のスコアをグラフ形式で確認できる必要があります。

1 ユーザー = 60 ベット = 30 日 (ラウンド。合計ポイントと毎日のポイントが記録されます。

4

1 に答える 1

2

ここでいくつかのことが起こっています。

まず、あなたはパフォーマンスを気にしているようです。あなたが言及した設計は、パフォーマンスの観点からは問題ないはずです（ただし、以下を参照）-データベースは大量のデータの処理に非常に優れています。MySQL では、このような設計は、実際のパフォーマンスの問題なしに数百万のレコードに成長する可能性があります。

第二に、しかし、設計上の問題があります。あなたは本当にデータベースの設計を読むべきです- それは大きすぎて1つの質問で答えます - しかし、あなたの member_points テーブルはユーザー名ではなく member.id 列にリンクする必要があります (それが主キーであると仮定します) - ユーザーがユーザー名を変更した場合、すべての member_points レコードを更新する必要があります。

于 2013-02-22T23:13:36.083 に答える