2

2つのテーブルがあります。

表A：曲のリスト、曲のアートワーク、mp3リンク、タグなどが含まれています。

表B：登録済みのユーザー情報、ユーザーID、ユーザー名などが含まれています。

曲に星評価システムを追加しようとしています。登録ユーザーは、曲ごとに1回だけ投票できるようにしたいと思います。

したがって、私の計画は当初、3番目のテーブルを作成し、JOINを使用することでした。

表C：songID、合計スコア（投票されたすべての投票の合計）、vote_count（投票数）を含み、jQueryでクライアント側の計算を実行して平均投票を返します。

非常に大きなデータセットを処理するため、これがパフォーマンスに最適であると考えました。

もちろん、この方法を使用すると、ユーザーが何度でも投票することを防ぐことはできません。

したがって、私の質問は、これがプロジェクトの鍵であるため、曲自体のフィルタリング/ソートのパフォーマンスを低下させることなく、不正行為（つまり、表Cの投票者のuserIDの保存とチェック）から保護するためにどのデータベース設定が最適であるかということです。

このリクエストを明確にしたことを願っています。そうでない場合はお詫び申し上げます。

4

4 に答える 4

3

投票表を作成する：（[userID、songID]、評価）

たぶん、より高速なアクセスのためにsongIDにインデックスを付けます。

于 2011-11-28T13:49:47.293 に答える
1

3番目のテーブルは次のように構成する必要があります。

Song ID
User ID
Star Rating

-（曲ID、ユーザーID）に一意のインデックスが付いています。（誰が投票したかを知るには、ソングIDとユーザーIDを一緒に保存する必要があります。これを回避する方法はありません。）

特定の曲の平均評価を返すには、単純に

select AVG(`Star Rating`) From `Rating Table` where `Song ID` = ?

インデックス付きのテーブルでは、評価が1000未満の特定の曲の平均を選択すると、妥当なアクセス時間が得られます。

于 2011-11-28T13:54:54.127 に答える
1

これを試して：

  • アルバム| アーティストID、アートワーク
  • アーティスト| 総合評価
  • 歌| アーティストID、アルバム、評価
  • ユーザー

そうすれば、アーティスト、曲、アルバムなどでプルアップできます。

于 2011-11-28T13:59:34.467 に答える
1

レーティングをどの程度最新にするかによって異なりますが、スターレーティングの場合、必ずしも分単位である必要はありません。だからあなたは持つことができます

vote table: ([userID, songID], rating)

Tom van der Woerdtが提案したように、ただし、各曲に星の評価を追加して、容量がある場合は毎日または数時間ごとに再計算することもできます。

于 2011-11-28T14:00:26.593 に答える