2

非常に単純なポイント システムをサイトに追加しようとしています。私の SQL データベースには、ポイントを付与するための表があります。これは、管理者がユーザーのポイントを任意の量だけ増やすことができ、ポイントが増える理由も示しているためです。したがって、少し単純化すると、この表には、管理者がポイントを付与するたびに付与されるポイント数、根拠、およびユーザー ID が含まれます。ここまでは順調ですね。

ただし、最高の合計ポイントを競うサイトには 10 のユーザー グループがあります。サイトのメンバーはすでに 10,000 人を超えているため、1 つのユーザーグループのポイント数は簡単に合計 15,000 に達する可能性があります (確かに、ほとんどが非アクティブです)。競合するユーザーグループとその合計スコアを表示するリーダーボードを作成したいのですが、システムを実装する際に毎回ポイントを合計するのに時間がかかりすぎるのではないかと心配しています。質問は次のとおりです。ポイントの集計をデータベースに保存する必要がある場合は、どのレベルで保存する必要がありますか? ユーザーごとの合計ポイントのフィールドをユーザー テーブルに用意し、その場でそれらを合計して、ユーザー グループのランキングに使用する必要がありますか? それとも、ポイントが 1 人のユーザーに追加されるたびに更新するユーザー グループごとに集計フィールドを用意する必要がありますか? 実際にシステムを実装する前に、

4

2 に答える 2

1

ハードウェアによって異なりますが、数千行を合計しても問題ありません。ただし、絶対に必要な場合を除いて、すべてのユーザー スコアを合計することは避けてください。各グループの合計スコアを保存するロールアップ テーブルを追加し、夜間に cron を実行して合計スコアを検証することをお勧めします (基本的に合計を行ってから、絶対に正しい値を保存します)。

付与されたポイントとその理由を記録する表を追加することをお勧めします。また、ユーザーごとに合計スコアを個別に保存し、ログ テーブルとグループごとの合計スコアを含む別のテーブルへの挿入と同時に更新します。それはあなたの活動レベルでうまくいくはずです. 論争が多すぎる場合は、グループの合計スコアの非同期更新を行うこともできますが、問題はありません。

于 2013-02-25T23:50:05.557 に答える
-2

正直なところ、集計は 1 万行未満で 1 秒未満で計算される可能性があります。運用データベースをアトミックのままにして、各ポイント トランザクションを保存し、クエリ時に集計を計算する必要があります。本当にしたい場合は、集計を事前に計算してマテリアライズド ビューにすることもできますが、そうする必要はないと思います。

句を使用してマテリアライズドビューを作成できます

   refresh fast start with sydate
     next sysdate + 1/24

- 1 時間ごとに更新する。

リアルタイムの集計データは得られませんが (1 時間ずれている可能性があります)、データが膨大になると、集計クエリのパフォーマンスが大幅に向上する可能性があります。あなたのデータは現在のものなので、私は気にしませんが、あなたのパフォーマンスは問題ないはずです。

編集：なぜ私が反対票を投じられているのかわかりません。これは、集計をテーブルに格納するよりも優れたソリューションだと思います。

于 2013-02-26T01:49:46.373 に答える