Adobe AirにはSQLiteをベースにした、ローカルDBが標準で付属する。これによって、Webから取得したクエリを保存して、検索しやすい形で保持することが可能になる。さらに、アプリケーションが強制的に終了した場合に対しても安心できる。WebブラウザでもローカルDBとして用意される向きにある。SQLiteを前提としていることが多いようだ。
AirではAirrecordというActiveRecord系のO/Rマッパーが存在しており、それをさらにカスタマイズして利用してみた。当初はこれでうまくいっているように見えたのだが、データベースに入れる項目を増やそうかと考えたときに、面倒だと思える作業が発生した。
それは古いDBと新しいDBとの互換性であり、古いDBであれば、新しいDBにするために列を増やすためのSQLを発行しなければならない。テーブルのスキームを1つずつ確かめ、必要があればデータをダンプし、移動するという作業はひどく面倒な気がしたので、項目を新しくすることも出来ず、そのまま意欲がそがれてしまった。サーバのDBを変更するのであれば、そこまで難しい問題ではないのだが、クライアントDBを変更するという点については、様式すら思い浮かばなかった。
この問題を数ヶ月放置していたのだが、解決するにはどうしたらよいのか、いくつか考えがまとまってきた。
1つは、データベースにバージョン情報を載せ、古いバージョンであれば、変更箇所のcreateなりalterなりを食わせる方法だ。以前はスキーマを確認して無ければ追加するという方法しかないと思い込んでいたが、バージョン情報で管理する方が楽そうだ。
もう1つはSQLite上にスキーマレスなデータベースを構築することだ。最近は大規模情報の管理のためにNoSQLという風潮が高まっているが、スキーマそのものを定義しない点に着目して、独自の機構を作るとうまくいくのではないだろうか、という発想だ。この手法であれば、スキーマを決定する苦痛から逃れられるが、NoSQL独特な設計が求められることだろうと思う。
スキーマレスには惹かれるものがあるのだがどーなるのか分からない。かつ、ActiveRecordな実装が存在しているので、現時点ではデータベースのバージョン情報を管理するmigrationを実装した方が楽そうだ。javascriptのActiveRecord実装であるactiverecord.jsがmigrationに対応しているそうなので、それを見ながらのんびりやった方がよさそうだなーと感じる次第である。
（ちなみにSQLite上でNoSQLするなら、mysql上のNoSQL実装であるRailsプラグインfriendlyを参考にするのが良さそうだった。）