良いアイデアというか設計がまとまらず悩んでいます。
現在の状況は、商品DBがありまして1レコードずつに商品データが格納されている状態です。
そこに、人気投票のフィールドを追加するのが一番簡単なのですが以下の問題があります。
1.ただ単に加算するので、日別、月別、年別などにわけることが出来ない。
2.1商品に対して1日1回の投票にしたいのですが、この場合javascriptでしか制御できないため無効にしている人には効果が無い。
3.商品レコードを呼び出して、人気フィールドの値に加算するため最低2クエリ必要。なるべく1回にしたい。
解決策として以下の処理を考えています。
1.投票DBを制作し1クリック毎にレコードを追加。
この場合、Cronなどを使って一定の期間で何らかの処理をしないと量が多くなりそう…
どのくらいの、期間でどんな処理をすればよいのでしょうか?
2.商品毎にカウントDBを作成する。
テーブルが多くなりすぎて面倒そうです…
日別、月別、年別の集計のほかに前日比みたいな感じも機能として欲しいのですが、
どう、うまくまとめれば良いでしょうか?
【0】主催者の読みや要求はどのくらいなのかによります
この手の設計には「単位時間あたりに投稿される件数」の見積が重要となりますので、
まずは、毎時どれくらいの投稿が発生するかを見積もってください(データベースの設計・構築に大きく関わります)
さらには、毎分どれくらいの投稿が発生するかも見積もってください(ロジックの設計・構築に大きく関わります)
投稿数は普段のページビューなどを参考にしますが、まったく新規の案件であるならば、
主催者がどのくらいの投稿数を希望しているのかを基準にして余裕を持たせるという考え方になったりします
【1】データベース側は専用のテーブルを用意するのが良いですね
・1.投票DBを制作し1クリック毎にレコードを追加が良いでしょう
毎時1万レコードの追加があったとしても容量なんかはしれてます
【2】集計タイミング
・投稿用とは別のテーブルを用意して、24時間に一度、集計結果を追記していけばよいでしょう
・途中経過が欲しければ1-2時間に1回などでも良いでしょう
ただし、常に最新の途中経過を表示するような仕様になってしまうと、
サーバ負荷が大きすぎると思うので、定時発表にしておくのが良いでしょう
・いずれの集計作業もサーバ自身が毎朝4時頃に行う維持管理作業を避けるようにしましょう
(サーバの設置されている国によって時差があるので注意)
【3】年別の集計
・長期運用を行うのであれば投稿用はパーティショニングを用いて分離しておくと良いでしょう
http://dev.mysql.com/doc/refman/5.1/ja/partitioning-management.h...
古いデータは集計結果だけを残すようにして、
月単位くらいでバックアップや消去していく流れにすれば管理は楽です
【備考】サーバ負荷は極力減らしましょう
javascriptが使えない状況では投稿できないようにしてしまうくらいのことが必要になる場合もあります
それは無理だとしても、クッキーを使って多重投稿されないような仕組みくらいは構築しましょう
ざっくりとした質問なので、以上ざっくりとお答えさせていただきました
(不明点があれば、コメント欄でよろしくです)
1.投票DBを制作し1クリック毎にレコードを追加。
この場合、Cronなどを使って一定の期間で何らかの処理をしないと量が多くなりそう…
どのくらいの、期間でどんな処理をすればよいのでしょうか?
集計処理なんて管理者がわで見れればよいもんじゃないの?
管理画面で見るだけならリアルタイムに集計して5分ぐらいかかっても良さそうなもんだが。
(さすがにそれ以上だとタイムアウトになる可能性があるね)
エンドユーザーにも見せたいなら集計結果格納用のテーブルでも作って、
定期的に集計結果を入れ替えるようにするだけじゃないかな。
どのくらいの、期間でどんな処理をすればよいのでしょうか?
逆に聞くけど、どのくらいの期間でどんなデータの見せたいの?
2.商品毎にカウントDBを作成する。
テーブルが多くなりすぎて面倒そうです…
テーブルが都度増えるという設計は無しだ。
詳しい説明は省くけど、あとで泣きを見るのは確実。