1

新しいウェブサイトの立ち上げまであと数日しかないため、開発プロセスの最後の仕上げを開始しました。アプリケーションのすべての部分を最適化するための努力により、すべてがうまく機能しますが、私のパートナーは、mysql データベースのサイズと、時間の経過とともに発生する可能性のある問題について質問しました. より具体的には、嫌いな機能 (cfc、jquery) を構築しました。これは完璧に動作しますが、多くの訪問者を引き付けることができれば DB サイズが大幅に増加します。

これが私たちのロジックです:
- IP を DB に保存するため、すべてのユーザーは 1 つの記事に対して 1 回だけ投票できます (賛成票または反対票)
。ストアド プロシージャ) と、データベース内の 100,000 行。それを 10、100、または 1000 で数えると、状況がわかります。

投票テーブルには4つの列があります
-typeID（voteUp = 1およびvoteDown = 2）
-articleID
-IP
-vCount（合計をカウントするために使用し、各記事の投票数）

ここでポイントを逃していますか？あなたの経験では、このタイプの機能を処理するための最良のアプローチは何ですか?

4

1 に答える 1

1

あなたのアプローチには何も問題はないと思います。データ ストレージ容量があまり制限されていないと仮定すると、長期間にわたって容量が不足することはありません。

もちろん、記事ごとに 1 つのレコードのみを使用することもできますが、ユーザーが投票するたびに更新のためにレコードをロックする必要がある場合、ボトルネックが生じる可能性があります。

考えられるのは、投票テーブルに日付/時刻フィールドを追加して、投票が記録されたときに保存することです。全体の投票を追跡するために、記事ごとに 1 行の追加テーブルを作成することで、たとえば 12 か月よりも古いすべての投票をクエリし、それに応じて新しいテーブルを更新し、古い投票を投票テーブルから削除できます。その機能をスケジュールされたタスクに詰め込めば完了です。そうすれば、IP 情報は失われますが (12 か月後または選択した期間後)、ストレージはいくらか回復します。

于 2013-10-15T11:54:02.980 に答える