熱にうかされてテーブル解析
前回高熱をだしたときは、
十干十二支の十干を思い出す、というのをやったけど、
今回の発熱は
「スターのテーブルのもちかた予想」
いまのスタフレとかのシステムは、
スターを削除してもスタフレ状態は解除されない。
これ、どうなってるんだろう、
と、熱にうかされて予想。
スタフレは、
システム上どういう判断で発生させてるんだろう。
日数をみてるということは、
日付をどこかに持ってるんだよなー
スターテーブルとかあるのかなあ。
細かい項目はおくとして、キーとかのからみでゆくと、
- エントリid
- エントリ主のユーザid
- スター主のユーザid
- 枝番（複数つけられるから）
- 日付（スターレポートの抽出条件にもなる。処理速度の面から、エントリidから毎回計算してることはないのではと思う）
このほかに、スター引用の文字列とかも多分もってる。
表示の仕方からいって、ポインタでなく文字列もち。
これでいま必要な要件はみたしてるはず。
あとは別サービスのテーブルみにいって取得する内容になる。
とすると、
スターがついたときに、スター主のユーザidと、当日日付<=データの日付+30でテーブルをみにいって、
あったらスタフレ。
スタコメの反映からいって、これはリアル更新されてる。
しかしその状態がスターを削除しても解除されないのと、処理速度の面から、
毎回エントリの表示ごとに判定を走らせているのでなく、
スタフレ状態テーブルをもって、ユーザidをそこにもってるっぽいかなあ。
- ユーザid
- スタフレユーザid
- スタフレになった日
スターをつけたときにテーブルみにいって、
データがなくてスタフレの条件をみたしてたら新規登録、
データがあったら日付更新。
ただし削除したときにはみにゆかない（多分）
バッチで30日経過データを削除してるんじゃないだろうか。
それが多分午前2〜3時のスターが重くなる時間。
スタフレテーブルの削除はあくまでバッチのみでリアル更新はしない、って仕様なのかなあ。
削除をリアルにすると負荷かなにかで問題点があって、
バッチ更新（削除）でのみ対応したいとか。
でもリアル更新／削除の要望は出す〜！
既存か対応済みだったら追加コメント出す！
たまらんぞ、いまの仕様では。
