Mac OS X 10.4で標準装備されたDatabase Eventsは、AppleScriptからコントロールするためのSQLiteフロントエンド（GUIなしアプリ）。AppleScriptの世界にしか登場してこない「なんちゃらEvents」というアプリケーション群は、AppleScript専用のGUIなしアプリで、OS側のさまざまな機能を手軽に提供できるようにすることを意図しているものだ。
・Database Events
・Image Events
・System Events
類似品に「なんちゃらScripting」というアプリ群があって、こちらもだいたい同様の目的のために用意されているものだが、旧Classic Mac OSの時代から引き継がれている種類のものだ。
・ColorSyncScripting
・FontSyncScripting
・ColorSyncScripting
・Keychain Scripting
・Digital Hub Scripting
・URL Access Scripting
これまで、データベースエンジンそのものやデータベースのフロントエンドなどはMac OS Xに装備されていなかったので、このDatabase Eventsは拍手喝采をもってScripter連中に受け入れられる……はずだった。
ところが、このDatabase Eventsは……「これでどうやってデータベースを操作するのか？」という程度の辞書しか備えておらず、とくにソートのための用語が存在しないことで、早々に「使えない」ものとして考えられてきた。
検索のためのキーワードも見つからない。ソートは絶対無理……そんなべらんめぇなデータベースが世の中にあるとは思いたくないが、Database Eventsはまさにそれに該当するのであった。さらに追い打ちをかけるように、「データベースの生成はそれほど速いものでもない」とも言われてきた。
かくして、2005年のTigerの登場以来（2005/4/29）、３年近くずっとDatabase Eventsは「なかったもの」として扱ってきた。
その認識が、MacTech Journalのバックナンバーを入手したあたりから変わりはじめる。どうやら、検索については行えることが分かってきたのだ。
tell application "Database Events"
tell database "Super Heroes"
set aRes to first record whose name = "Superman"
end tell
end tell
tell application "Database Events"
tell database "Super Heroes"
set aRes to first record whose value of field "Secret Identity" contains "Parker"
end tell
end tell
こんな感じだ。さっそく、サンプルを集めてきたり、試行錯誤したりして……
「DB作成」
「Database Eventsを起動して、オープン中のDBを数える
パスを指定してDBを作成する」
「既存のDBを指定してオープンする」
「Database EventsのQuit Delayを指定」
「すべてのDBをクローズして終了」
「Database Eventsを終了する」
「DBの特定フィールドをキーにして、キーワードに一致するレコードを検索し、該当レコード中のフィールドの値を取り出す」
「DBの特定フィールドをキーにして、キーワードに部分一致するレコードを検索」
「DBの特定フィールドをキーにして、キーワードに一致するレコードを検索
DBの特定フィールドをキーにして、キーワードに一致するレコードを検索し、該当レコード中のフィールドの値を変更する」
といったスクリプトをまとめてみた。この手の基礎的なサンプルをどれだけ作っておけるかで、後になって楽ができるかどうかが決まる。
とはいうものの、依然としてソートはできない状況。SQLite自体にソートの命令がないことは考えにくく、Database Eventsのソート機能不在については、どーにかできないものかと思っていた。
Database Eventsの機能を使ったソートはできない。だが、その気になれば……AppleScript自身でソートルーチンを記述して、ソーティングを行うことは可能だ。
ここで、Database Events自体の機能について概略をまとめておく。
……DBを作成してフィールドを定義し、データを置いておく「容れ物」として使える存在である。さらに、レコードごとにフィールド構成がバラバラであってもOKという、XML系データベースのようなたたずまいである。Database Eventsで作成したデータベース（「.dbev」ファイル）は、どうやらBlob（大きなデータをストアしておけるバイナリ形式のフィールド）で構成されているらしく、ダンプしただけではその内容を伺い知ることはできない。それほど独自の形式などは使っていないと思いたいのだが、とにかくそんな感じで……全部XMLでストアされている、とかいう構成ではない。CoreDataで作成したデータベースなら、デフォルトではXML形式でデータがストアされており中身も見たい放題なので……同じSQLiteをベースとしながらも随分と異なる世界観を持つソフトといえる。
Database Events自体は、launchするまで起動していない。起動して、quit delayで指定した時間が経過すると勝手に終了してしまう。GUIのたぐいは一切持っておらず、Database Eventsが起動しているかどうかは、System Eventsでプロセスの一覧を取得して確認しておく必要があるだろう。
本来であれば柔軟性のきわめて高いデータベースとして使えるのだろうが、ソートがないために「まっとうな用途」には使いにくいものとして認識されてきた。
通常のAppleScript単独で考えればソートは「できないも同然」なのだが、これが……AppleScript StudioでTable ViewのUIの中にデータを入れるように考えると……突如として状況が変わってくる。Tableにデータを表示させるには、Table ViewのDatasourceを作成し、Datasourceの内容に対してリストを突っ込む処理を行うことになる。Database Eventsのデータベースも、Table Viewに表示させたりすることだろう。
で、再三繰り返して説明しているように、Database Events自体にソート機能はない。だが、Table Viewにはソートの機能が存在している。ふりがなフィールドをクリックするとソートされるといったUIを構成することが可能だ。
ソートに関しては、Table Viewに行わせることで、検索とソートが可能になり……さらに、自由度の高いDBを構成できる……これはなかなかよさそうではないか。Database Eventsでどの程度の操作ができるのか、GUIを伴った評価用アプリケーションをひとつ作ってみるとよいだろう。たとえば、バーコードリーダーでデータのエントリを行うようなアプリケーション。
フィールド構成がレコードごとにバラバラ、といったデータベースを作るのは骨が折れる仕事だ。前に、FileMaker Proでそういう構成のDBを作ったことはあったのだが……ブラウズはできるものの、どーやって入力したものか皆目分らないというシロモノになってしまった。柔軟な構成のDBを、柔軟に入力できるようにできるとよさそうで（まるで紙に記入するみたいに）、そのためにこのDatabase Eventsは利用できるのかもしれない。
ああ……あとからあとから、いろいろとアイデアが湧いて出てくる（汗） 人は不完全な道具を前にすると創作意欲を喚起されるものなのだろうか？ それとも、そういうことを意図して一見不完全に見える道具が提供されているということなのだろうか、、、