さて、いろいろこちら側の研究を進めたことですから、今日もそのことを書こうと思います。
Site System
今回は、主にSiteSystemの検討を進めました。やったことはまあ、WikiのSite Systemのページあたりを見ていただければ分かると思いますが、データ構造や、その保持方法について考えています。
とりあえず、レコードによって内容が変わりそうな部分は、一つのテキストフィールドにまとめて保持すると言うことで、何とかデータベースでも可変長レコードのテーブルを作ることはできますが・・・。
サンプルテーブル | 固定レコード1 | 固定レコード2 | 可変レコード |
---|---|---|---|
1 | 20 | test | name:sample category:test |
1 | 21 | test2 | name:sample |
とまあ、こんな感じ。ちょっとぱっと見不細工ですが、可変レコードをSELECT文に使いたいときは正規表現を使えば何とかなるし、悪くはなさそう。
まあ、そうするとどうやってディレクトリ構造を維持するの? ということになるんですが・・・うーん。どこかに何か、そういうこと*1をやってるものがあったと思うんですけどね・・・。忘れた。
それを思い出せれば、既存のDBMSでも行けるかもしれないですね。
あとは、クリエイタがやること。まあ、あんまり大きくしても仕方ないですが、クリエイタがやらなきゃいけないことは少なそう。ほかのCGIから呼び出せるようにできると良いですが。
ひきつづきツリー構造について考えるかな。
TMemo
ツリー構造といえば、こっちもツリー構造です。アイディアを適当にまとめただけですが、WikiのTMemoのページに多少ながら書いています。
こっちはファイル管理が一所ではできないし、そもそもする気もないので一メモ=一ファイルで行く予定。
添付ファイルも入れられなきゃいけないので、一メモ=一ディレクトリになってもおかしくない。
こっちは完全にローカルで動くソフトで、ネット対応という形になるので、楽っちゃ楽です。がんばりますよ。
今回コンセプトにしたのは、SEPATAが一番大きいかも。残念ながら作品自体は見られなかったSEPATAですが、InternetArchiveよりその断片を見てくることはできました。うわっ、新バージョン実装予定のこと半分は実現してるじゃないの、さすがだなあ。こっちも負けてられない。
*1:二次元のテーブルで、多次元のツリーを実現する