web-dev-qa-db-ja.com

ORDER BYおよびLIMITを使用して各グループのn行を合計します。ここで、LIMITは別のテーブルに基づいています。

ファンタジーサッカーゲームのユーザーのリーダーボードを作成する必要があります。ゲームの簡略化されたデータベースは次のとおりです。

  • userssquadsにsquad_playersがあるmatchesごとに（transfer_periodによって関連付けられます）
  • players各matchesにmatch_pointsがあります
  • squad_playersにはposition、priorityがあります。 priorityは、squad_playersがmatchesにない場合の置換の順序です。
  • squads have formationsこれは、各プレーヤーから選択するプレーヤーの最大数を決定しますposition ordered by priority

データベースはMySQL 5.6であり、usersの最大数は10Kです。

squad_players、squads、matches、match_pointsを（順番に）内部結合して、プレイした各squad_playersのポイントを取得できます（playersプレイしなかった人にはmatch_pointsがありません）。

[〜＃〜] sum [〜＃〜]ポイントxsquad_playersのポイントsquadsに苦労していますxはformationsにあり、squad_playersのpositionによって決定されます。

相関サブクエリを使用してGroup n with Top n-rowsのバージョンを変更しようとしましたが、成功しませんでした。

私のアプローチはここにあるべきですか？

私の期待される出力はこのようなものです

|---------|-----------|------------|----------|
| User ID |  SQUAD ID | POSITION   |  POINTS  |  
|---------|-----------|------------|----------|
|   12    |    34     | defender   |    12    |
|---------|-----------|------------|----------|
|   12    |    34     | forward    |    2     |
|---------|-----------|------------|----------|
|  117    |    31     | midfielder |    5     |
|---------|-----------|------------|----------|

メモ：

  • 出力を追加する必要がありますが、問題の説明を反映していない場合があります。

  • サンプルデータセットリンク を調べると、normalized_squad_player_pointsという名前のビューが見つかります。これは、さまざまな統計を作成するために使用する非正規化テーブルです。

リーダーボードの最終出力は次のようになります

|---------------------|------------------|
|      User ID        |       Points     |
|---------------------|------------------|
|          12         |         34       |
|---------------------|------------------|
|          56         |         32       |
|---------------------|------------------|
|          117        |         31       |
|---------------------|------------------|

追加情報

mysqldatabase-designmysql-5.6group-bygreatest-n-per-group
5
Sakibul Alam

最終的に実装したソリューションは、positionsとformationsの異なる順列に基づいてクエリをより単純なものに分割することでした。また、中間結果を保存するためにいくつかのテーブルを追加する必要がありました。すべてのクエリ（約42）をトランザクションで実行しました。

これはかなりうまくいき、サーバーのリソースを過負荷にすることなく、妥当な時間で完了しました。

1つの巨大なクエリでそれを行うことは、最初から悪い決定だったと思います。それをより小さなクエリに分割することで、プロセスを保守可能かつ柔軟にすることができました。

1
Sakibul Alam