タイトルを見ても、「だったら早く決めたらいいだろ。」と言われるかも知れんので、
技術的な葛藤を書く。私の頭の中で考えていることである。ちょっと文章にすると、
客観的に見つめなおせるかな。

もしかしたら、Webプログラミングの初学者で、初めてDB設計する
人にとっては、こういう風に考える馬鹿もいるのだ。と、少しは勉強になるかもしれない。

はっきりいって後述する、ダイアリーカウントの概念さえなければ、こんなに悩む必要はなかったのに。

前提条件

日記を書いた後のデータは、以下の通り。

  • 年=西暦 年
  • 月=西暦 月
  • 日=西暦 日
  • ダイアリーカウント=同じ日に複数登録する場合の処理 その日のうちで何番目の記事か。
  • 一列表示する=画像を横に三つ並べて表示するのか、たてに並べて表示するのか
  • カテゴリー=この記事は、どのカテゴリーに属するのか
  • コンテンツ= 日記の内容(HTMLタグはある程度認める)
  • 画像1 =アップロードされた画像
  • 画像2 =アップロードされた画像
  • 画像3 =アップロードされた画像
  • 画像alt1 =画像のAlt属性
  • 画像alt2 =画像のalt属性
  • 画像alt3 = 画像のAlt属性

でまぁ、これをそのまんまデータベースとして保存すればいいが、
これだとちょっと困ったことになるのである。

まず、一番簡単な方法

データベースファイルをdb.datとかいう風に、一つのファイルで対応する

こうすると、システム的にすごく楽。
でも、データ量が増えてくると、読み込みにすごく時間がかかる。
(一年くらいつづけると、一日分を表示させるのに、5分くらいかかりそうだね。)

なので、データを分散管理する必要性が生じる。
データを分散させようと思ったら、辞書みたいに、キーワードか何かで、抽出しないといけない。
そこで、年-月 というフォルダを用意して、月ごとにデータを分散してみよう。
そうしたら、例えば、2006年の9月のデータは、
2006-09 フォルダの中のデータを検索すればよいことになる。一ヶ月分のデータは、
そんなにたいしたことがないはず。

これで、前のシステムでは、大体109倍の検索の高速化を達成できた。
http://www5f.biglobe.ne.jp/~ymlab/forme/2006_healthcheck_report.pdf#page=17
ちょっと前の方にいくと、それの理論を書いた。その理論になるための前提条件が真であるための証明は、
http://www5f.biglobe.ne.jp/~ymlab/forme/2006_healthcheck_report.pdf#page=35
である。

なら、もっと高速に検索するためには、2006年9月1日 とか、日にちで分割して行えばよいではないか。
という意見に達する。
しかし、そうすると、複数の日にちを表示する場合において、
ファイルにファイルポインタを合わせる行為は、結構時間がかかるので、
逆に遅くなってしまうのである。

それに、Microsoftの仕様では、一つのディレクトリに存在できるファイル数は、65535という制限がある。
あ、これは充分か。

これで、日にちによる検索は、解決できる。
しかし、次の問題がある。
カテゴリー検索した場合の対応である。

もし、カテゴリーで検索された場合、日にちだけでは、対応できず、すべての記事について、カテゴリー情報を
洗いなおさなくてはならなくなる。
それは避けたい。そこで、それには、記事情報のほかに、全体の辞書ファイルを作成してしまう手段である。
要するに、記事のファイルのほかに、全体を管理するファイルを用意するのである。そして、それには最低限の情報しか載せない。

#記事番号,カテゴリー,年月日
10001,ZVSDRGSA,2006-09-01
10002,BTELSRLH,2006-09-02
10003,ZVSDRGSA,2006-09-03

こんな感じ。
カテゴリーが変な文字な理由は、カテゴリー名を日本語にしてしまうと、漢字コードや、よく似た漢字。
子孑とか、日曰とか。混乱のもとなので、それをランダムなアルファベットに対応させてあげると、よいのである。
8文字なのは、重複を避けるためである。2文字だと、26*26種類しか作れんし。充分か。

まぁ、これで、M永というカテゴリーが、ZVSDRGSAに対応していたという条件の元では、
M永カテゴリーを抽出しようと思えば、この辞書ファイルをさくっと検索して、
「10001番、10003番」という情報をゲットして、

10001番は、2006年09月01日だから、2006-09フォルダの中!
と、すべてを一個一個検索していくよりも、圧倒的な検索効率の向上に作用するのである。
よくあるやり方だが、この方法を誰にも教えられずにひらめいた時は、ものすごく自分が天才だと
思ったものである。この検索方法が本に載っていて、ひどくがっかりした覚えがある。
ちなみにこういう検索方法を、インデックス検索という。

これでカテゴリー問題は、解決できる。
で、一日に複数のデータがある場合の対応なのである。これはどうやったら高速に検索できるのか、
想像がつかない。
xml.phpの仕様的にも困るのである。
xml.phpは、XML連想配列にパースする。当然一つの場合は、変数、二つ以上の場合は、
配列として認識するので、一日の記事数が一つの場合と、二つ以上の場合は、プログラムの実装を
変更しないといけないのである。

だから、ダイアリーカウントの概念を必要とする。
しかし、検索するほうも、X年X月X日は、いくつの記事があるのかを把握しておかないといけない。
そのためのファイルを用意して・・・うげー、めんどくせー。なんかもっといい方法はないの?

というのが今の課題なのである。

あ、普通の人は、こんな面倒なことはせずに、DBMS使うので、そっちを使ったほうが、安全で、高速に検索できるので、
こんなことを考える必要はなくて、そっちを使ったほうがいいですよ。

今作っているのは、学校用なので、私が転勤した場合データ復旧ができなくなるので、DBMSを使わないだけです。