3.2 技術的なこと

セッションキー

セッションキーは課題提出システムと共用とした。いわゆる single sign on 的な格好にしたかったためである。

MySQL

課題提出システムは DBMS に PostgreSQL を利用したが、掲示板システムは MySQL である。理由は処理が低負荷・高速であるため。掲示板システムはレポート提出システムと異なり、負荷が圧倒的に高い。一人の利用者が継続的に画面遷移・リロードを行う。

また、データは read がほとんどで write の機会が極端に少ない。そのために read 処理が高速なものが良い。

既読記録・マークの限界

既読情報、マークの情報については実装方法が幾らでもあり得る。ただし問題は負荷の低減（処理の高速化）である。基本的な考え方は以下のとおり。

• なるべく各記事の履歴が高速・低負荷に得られるように。
  
• ユーザがある掲示板にアクセスした時に既読履歴情報を作る。つまり記事投稿されるたびに全ユーザの既読履歴に未読を追加するようなことはしない。
  
• 古すぎる記事についての既読管理は必要ないだろう。（すべて既読となって良い）

1. スレッド単位ではなく掲示板単位に記事通し番号をつけ、
   
2. 利用者・掲示板ごとに一レコードとなる既読管理テーブルを用意し、
   
3. 既読とマーク情報を一項目の可変長文字列で記録する。
   
4. 既読、マークはビットパターンで詰める。

具体的なレコードイメージは以下のようになる。

このままだとビットパターンが爆発するので、ある一定数を決めてそれを越えると積極的に古い記録を切り捨てて、それ以前の記事は全て既読扱いとする。どれだけ切り落としたかを offset として別項目に記録する。

これで各利用者が掲示板に一回アクセスするたびに、ただ一度だけの履歴レコードの取得を実施するだけで既読・マークの情報が得られる。そのかわりビット位置計算などが加わるが、おそらくその程度の CPU 負荷よりも DB アクセスを節約すべきだろう。

実際の実装では可変長文字列は 255 バイトを越えると処理が重くなる事が実験で確かめられたため、それ以前の位置に限界長を定めた。およそ 1000 記事が最大履歴保持数であり、それ以上の記事が投稿された場合、最新から 1000 記事以前の記事は一律に既読と処理される。が、恐らく多くの読者にとってそれほど過去の記事についての記事単位での既読・未読にはほとんど意味がない。

3.3 設計上の失策

残念なことにどこを間違えたのか理解出来るほどの利用例や経験量が出なかった。