SQLクエリでこれを行うと述べたので、その中でサンプルを提供します。
テーブル/ビューがある場合Pages
、このようなもの
Pages
-----
page_id:int
views:int - indexed
comments:int - indexed
それからあなたは書くことによってそれらを注文することができます
SELECT * FROM Pages
ORDER BY
(0.3+LOG10(10+views)/LOG10(10+(SELECT MAX(views) FROM Pages))) +
(0.7+LOG10(10+comments)/LOG10(10+(SELECT MAX(comments) FROM Pages)))
私は意図的にビューとコメントの重み付けを不均等にしています。ビュー/コメントで均等な重み付けを維持することで発生する可能性がある問題は、ランキングが自己達成的な予言になることです。ページがリストの一番上に返されるため、より頻繁にアクセスされ、より多くのポイントが得られます。リストの最後に表示され、より頻繁にアクセスされ、より多くのポイントが得られます....
上記の式は、これまでの統計に基づいてランキングを表示します。そのため、先週の閲覧数/コメント数が、昨年に蓄積された別の記事と同じ数の記事には、同じ優先度が与えられます。日付の範囲を指定するたびに数式を繰り返し、アクティビティの多いページを優先することは理にかなっている場合があります。
0.3*(score for views/comments today) - live data
0.3*(score for views/comments in the last week)
0.25*(score for views/comments in the last month)
0.15*(score for all views/comments, all time)
これにより、「ホット」なページには、最近あまりアクションが見られない同様のスコアのページよりも高い優先度が与えられます。今日のスコア以外のすべての値は、スケジュールされたストアド プロシージャによってテーブルに保持できるため、データベースは多くのコメント/統計情報を集計する必要がありません。今日の統計のみが「ライブ」で計算されます。さらに一歩進んで、ランク付け式自体を計算し、毎日実行されるストアド プロシージャによって履歴データ用に保存することができます。
編集: 0.1 から 1.0 までの厳密な範囲を取得するには、次のような数式をモチーフにします。しかし、私は強調します - これはオーバーヘッドを追加するだけで不要です - 優先度の絶対値は重要ではありません - 他の URL に対する相対的な値だけです。検索エンジンはこれらを使用して、URL A は URL B よりも重要/関連性が高いかという質問に答えます。これは、絶対値ではなく、優先順位 (どれが最も大きいか) を比較することによって行われます。
// 非正規化 - x はページ ID un(x) = 0.3*log(views(x)+10)/log(10+maxViews()) + 0.7*log(comments(x)+10)/log(10 +maxComments()) // 元の式 (現在は疑似コード)
最大値は 1.0、最小値は 1.0 から始まり、ビュー/コメントが作成されるにつれて下方に移動します。
un(0) を最小値として定義します (上記の式では、ビュー (x) とコメント (x) は両方とも 0 です)。
0.1 から 1.0 までの正規化された数式を取得するには、ページの正規化された優先度である n(x) を計算します。x
(1.0-un(x)) * (un(0)-0.1)
n(x) = un(x) - ------------------------- when un(0) != 1.0
1.0-un(0)
= 0.1 otherwise.