テキストデータベースとは、要するに一件の情報を一行のテキストにするというルールで書き続けたテキストファイルを、自分用のなんでもデータベースとして使おう、という主張にほかならない。住所録のようなデータを入れてもいいし、本や記事の抜き書きをしてもよい。

ただひとつのルールはひとつの情報（レコード）の途中で改行を入れない、ということだ。つまり1レコード1行。

これは検索と抽出の都合でこうなっている。grep式の検索ソフト（Macならたとえば「ファイル検索犬ぽち」など）を使うにしても、Perlなどを使って抽出するにしても、行単位にしておかないと、処理が面倒になる。行単位にしておけば、検索語を含む行（レコード）だけを、一瞬にしてファイルとしてまとめることも可能だ（これは強力）。

しかし、このテキストデータベースに問題がないこともない。最大の問題は、何といっても入力が面倒なのだ。データによっては表のような形式で記述したほうが手っ取り早いものもある。複数行にわたるデータは天声人語方式で、改行記号の代替えとして「◆」を使うようにしているが、入力しにくいし、読みにくい。

単純にMac OS Xになって、愛用していた検索ソフトが動作しなくなったということもある。

そしてもうひとつのネックが、蓄積するまでの「かったるさ」である。

こうしたデータベースは、おそらく１万件くらいのレコードが入力されてはじめてその効力を発揮する。それはたしか「知的生産の技術」にも記されていたはずだ。入力されたデータ数が少ないうちは、検索しても思わしい結果が出てこないものだから、ついつい利用率が下がる。検索で使わないから入力しないという循環に陥ってしまう。

であるから、望むらくは、将来の夢の環境を目指して、シコシコと無味乾燥な努力を蓄積していくべきなんだろうが、人間、なかなかそうは高度にできていない。したがって白状してしまうと、私のテキストデータベースも、いささかいいかげんな運用になっている。テキストデータベースに何もかも放り込む、という意気込みとは別に、各種資料がファイルの形でハードディスクに蓄積されてしまっているのだ。

いままでは、ずっと「ああ、これではいけない。テキストデータベースに一元化しなくては」と思っていたのだが、これは考えてみると、逆。

ファイルの形で残ってしまうというのは、そっちが便利であるからであって、それが基準にあわないとしたら、基準の方が間違っているのだ。

というのは、Mac OS Xになって、iPhotoを見て、遅まきながら悟ったことだ。

で、これらの反省をふまえて、現時点での構想は、

• 何でも（テキストでも画像でもファイルでも）たたきこめるデータベースでありたい


• しかし構造的にはテキストデータベースと同じく、フィールド数の極めて少ないものでありたい

こんなことができるだろうか？　できんじゃないの？　それこそPHPとSQLでやればどうなんだろ。

そう、思った次第。

ま、長くなってしまったが、サーバを導入しようと思ったのは、そんな夢もあったんですね。