3

この投稿は、この回答済みの質問のフォローアップです:ユーザー ID のリストを保存するための最良の方法。

私は、cletus と Mehrdad Afshari の、正規化されたデータベース アプローチを使用するという壮大なアドバイスを受けました。次の表は、適切な最適化のために適切に設定されていますか? 私はMySQLの効率性に慣れていないので、これが効果的であることを確認したいと思います.

また、ゲームの平均評価と総投票数を求める場合、次の 2 つのクエリをそれぞれ使用する必要がありますか?

SELECT avg(vote) FROM votes WHERE uid = $uid AND gid = $gid;    
SELECT count(uid) FROM votes WHERE uid = $uid AND gid = $gid;

CREATE TABLE IF NOT EXISTS `games` (
  `id` int(8) NOT NULL auto_increment,
  `title` varchar(50) NOT NULL,
  PRIMARY KEY  (`id`)
) AUTO_INCREMENT=1 ;

CREATE TABLE IF NOT EXISTS `users` (
  `id` int(8) NOT NULL auto_increment,
  `username` varchar(20) NOT NULL,
  PRIMARY KEY  (`id`)
) AUTO_INCREMENT=1 ;


CREATE TABLE IF NOT EXISTS `votes` (
  `uid` int(8) NOT NULL,
  `gid` int(8) NOT NULL,
  `vote` int(1) NOT NULL,
  KEY `uid` (`uid`,`gid`)
) ;
4

5 に答える 5

6

ゲームの平均投票数:SELECT avg(vote) FROM votes WHERE gid = $gid;

ゲームの投票数:SELECT count(uid) FROM votes WHERE gid = $gid;

これより小さいユーザー ID またはゲーム ID はない0ため、それらを符号なし整数 ( ) にすることができますint(8) unsigned NOT NULL。

ユーザーが 1 つのゲームに対して 1 票しか投票できないようにする場合は、通常のインデックスだけでなく、テーブル内に主キーuidを作成します。gidvotes

CREATE TABLE IF NOT EXISTS `votes` (
  `uid` int(8) unsigned NOT NULL,
  `gid` int(8) unsigned NOT NULL,
  `vote` int(1) NOT NULL,
  PRIMARY KEY (`gid`, `uid`)
) ;

主キーのフィールドの順序 ( first gid、 then uid) は重要であるため、インデックスはgid最初にソートされます。これにより、インデックスは、特定の を選択する場合に特に役立ちgidます。特定のユーザーが行ったすべての投票を選択する場合は、別のインデックスをuid.

特に高負荷設定ではテーブルロックがパフォーマンスを低下させるため、ストレージエンジンには InnoDB をお勧めします。読み取りパフォーマンスのために、APC、Memcached などを使用してキャッシュ システムを実装できます。

于 2009-03-09T00:20:08.820 に答える
2

いいね。

グローバルIDと一意のIDのように聞こえるgidとuidの代わりにusers_idとgames_idを使用していたでしょう

于 2009-03-07T01:31:12.257 に答える
1

最終的に何をするにしても、必ず大規模なデータセットでテストしてください (膨大な数のユーザーを持つ予定がない場合でも)。

100,000 ゲーム、50,000 ユーザー、100 万票を生成するスクリプトを作成します。少し過剰かもしれませんが、その数のアイテムでクエリに何時間もかからなければ、問題になることはありません

于 2009-03-09T01:32:27.743 に答える
0

voted_on(DATETIME) 列も追加することをお勧めします。そうすることで、たとえば、特定の期間のゲームの傾向を確認したり、いつかスパム投票が発生した場合に備えて、不要な投票を正確に削除したりできます。

于 2009-07-03T04:25:47.430 に答える
0

これまでのところ良さそうです。インデックスと外部キーを忘れないでください。私の経験では、ほとんどの問題はあまりよく考えられていない設計からではなく、インデックスと外部キーの欠如から生じます。

また、ストレージエンジンの選択に関しては、トランザクションのセマンティクスだけでなく、(かなり複雑な/サイズのアプリで) innodb を使用しない理由をまだ見ていません。

于 2009-03-07T01:29:32.680 に答える