トップ «前の日記(2006-03-18 [J]) 最新 次の日記(2006-03-20 [J])» 編集

Eroge RSS Checker 運営記録

Categories | メモ | 運営 | 感想 | 記号変更 | 雑記 | 雑文 | 思案

合計: 今日: 昨日:
2006年
3月
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31

rss1.0

ここは、「Eroge RSS Checker」に関する運営の記録を書きとめておく場所です。第三者に説明する文体で書いていますが、大半は備忘録です。

  1. スクリプトを汎用化して公開する。---最終目標
  2. CSSを論理的に使う。---努力目標
  3. デザインを改善する。---努力目標
  4. 攻略の完全・不完全を出来る限り判別する。---努力目標
  5. 管理要員用のページの充実。---努力目標
  6. JANコードの入手先を探す。---躊躇中
  7. ブランドの複数登録。---大規模改修のとき
  8. 登録を簡潔にしつつ、marker登録を半自動化する。---暇なとき

2006-03-19 [J]

_ [メモ] 詳細フィルター機能はいいかも

今あるフィルターとは別にもっと詳細に設定できる機能があってもいいかもしれない。例えば、発売日制限(一定範囲内のみ表示する)とか、若いユーザーにとっては需要がありそう(20世紀のゲームの情報なんて興味ない人は多そう)。ただ、実行するにはデータベースの速度が遅すぎる、キャッシュを利用するのはパフォーマンスに問題があるかも。要思案。

_ [雑記] 管理人A=管理人B

あのサイトの管理人とあのサイトの管理人が同一人物だったと某所で地味に話題沸騰です。個人的には、「へぇ〜」という感じで面白いとは思いますが、それ以上どうとも思いませんねぇ。まぁ、わざわざ自宅サーバーを立てるなんて、どんな人だろうかと、疑問には思っていましたから、疑問が解けてすっきりはしてます。

私も3つのサイトを運営していますが、そういう人は結構いるそうですね。2chにそういうことを書くスレがありましたけど、すごい量を運営している人が結構いました。中には相互にリンクしている場合もありますけど、そうでない場合の方が多そうです。更新頻度は全部合わせて1サイト分のようですけどね。それにしても、なんででしょうね、そんなにサイト運営するなんて?

私の場合は、顔によって分けないとならないという面があります。ここに日常の日記書いてもだれも見たくないだろうし、万が一にも素性がばれるような、身近な話題も書きにくい・・・ということで日記というかなんというかなブログは別にしてます。レビューの方も別です。便宜なんて図ってませんよ、念のため。なぜ、レビューとERCを分けるかって?そりゃ、万一の場合に被害を最小限にしたいというのが本音ですかねぇ・・・・なんの被害かはまぁ色々ですいろいろ。

でも、最近は商品ごとにサイト作ったりしますし、そうした方が色々と都合がいいというのは確かですね。ただ、個人でサイトを分けるのは、内容にもよりますが、秘密主義的な性格の管理人さんに多いのだと思います、私みたいに。あの顔はこの顔を知っている人には見せたくない、みたいな。

_ [思案] データベース同期のために

同期をスマートにとりたい。まず前提を考えて見る。

データの取得にはSelect文しか使えない。

削除・更新・作成が行われる可能性があり、それを予測できない。

当方のデータベースは元データベースと完全には一致しない。

この3つだけで相当困難なのは分かると思う。差分がどこかにあれば分かりやすいが、何を差分とするのかというのも結構厄介だし、こちらからは元データベースへ働きかけることは出来ない。更新が行われないなら、IDの存在を確認してから、なくなっていたら削除、増えていたら追加とか簡単に出来るのですが・・・。それは無理です。

ですから、全データをとりあえず取得しなくてはなりません、これは前提です。失敗したらいじらない。ただ失敗はどうやって判断するか。中途半端にデータが送られてくる場合があるので、これを回避するため、現在のデータの95%以下の場合は失敗と見る、ということで多分大丈夫だと思う。

では、成功していたら?Replace文を使って更新するという手段が一番良さそうに見えるのですが、こうすると既存のレコードを消去して作成されるので負荷が掛かってしまう、そして消去されたレコードはそのまま残ってしまう。

そうなるとやはり、更新前にステータスフィールドの値を全レコードにおいて+1して、Select文で完全一致レコードを探し、あれば−1する、なければIDを検索して、あれば+100でもして、なければレコードを作成すればいい。という以前の方法が最適ということになると思うのですが・・・・この1とか100とかで意味分かるだろうか?かなり過ぎていますが、ちょっと見分けが付きにくいようにも思う。100の所を、10000くらいにした方がいいかも。

それでまずはいいとして、削除されたレコードをどうするか?IDがかぶらないのならずっと保持してもいいようなものも含まれている。したがって、ステータスコードによって変更や削除されたレコードを一覧表示して、存続など処置を決めることが出来るシステムを作るべきかもしれない。また、reviewpagelistテーブルのような非常にレコード数が多くなると、存在する場合の+1をする処理だけでも非常に強い負荷を与えてしまう。したがって、その場合のIDを配列として所持して、最後にWhere条件句で一気に処理する必要があるだろう。ただこれもこれで非常に強い負荷を与える。けれど、仕方が無いのかもしれない。

ということで、一覧表の作成(管理要員用)と上記の仕組みに変更することを今回の更新内容としよう。

お名前:
E-mail:
コメント: