ユーザーが曲をリクエストできるようにする2つのテーブルがあります。もちろん、複数のユーザーが 1 つの曲をリクエストすることもできます。
| Id | Song_Name | | Requested_Id | By_IP |
+====+===========+ +==============+=========+
| 1 | song1 | | 1 | 1.1.1.1 |
| 2 | song2 | | 1 | 2.2.2.2 |
| 3 | song3 | | 1 | 3.3.3.3 |
| 2 | 2.2.2.2 |
1 人のユーザーが曲を複数回リクエストすること (悪用) を防ぐために、もう一度リクエストしようとしているユーザーが特定の曲を既にリクエストしているかどうかを確認する必要があります。だから私はLEFT JOIN
最初のテーブルと2番目のテーブルの間で、曲ごとに1行を返す行ごとGROUP BY
にやっています。Id
問題:GROUP BY
グループ化されていないフィールドで予測できない値を返します。それはわかっています。SELECT
しかし、この IP がこのグループに存在する場合、特定の IP を含む行を返すようにするにはどうすればよいですか? IP が存在しない場合は、グループの他の行が によって返されSELECT
ます。
どうもありがとう!
更新:リクエストしたユーザーの数 (またはまったくないユーザー) に関係なく、曲をリストに表示する必要があります。したがって、SELECT はすべての曲に対して 1 つの行を返す必要があります。しかし、たとえば、IP 3.3.3.3 のユーザーが song1 をリクエストしようとしている場合 (これはすでに彼によってリクエストされています)、クエリは次のように返されると予想されます。
| Id | Song_Name | By_IP |
+====+===========+=========+
| 1 | song1 | 3.3.3.3 | (3.3.3.3 in case it exists, otherwise anything else)
| 2 | song2 | 2.2.2.2 |
曲ごとのリクエストの総数も取得する必要があるため、他のリクエスト (IP) とのグループ化も必要です。したがって、Count() を使用します。
回避策:必要なことを実行するのは非常に複雑なように思われるため (可能であれば)、回避策を考えています。GROUP_CONCAT() 集計関数を使用しています。これにより、そのグループのすべての IP が「,」で区切られて表示されます。そのため、探しているものがすでに存在するかどうかを検索できます。これの唯一の欠点は、この返される文字列の (デフォルトの) 最大長が 1024 であることです。これは、大量のユーザーを処理できないことを意味しますが、今のところは問題ありません。