2009-09-01 06:58:43
HTML5
Comments: 0
何やら色々なブログで「HTML5にSQLite3が組み込まれる」とか書かれているが、
そういう記事を書く人は、オープン規格で特定の製品名が名指しで定義されるのはおかしいと考えたら自然だと思う。
正しい事実はこうだ。
HTML5では、ローカル（クライアントサイド）にデータベースストレージを持つことが出来る。
HTML5はgoogleが強く推している規格で、先行してGearsというAPIを実装する事で浸透を図っている。
このGearsでSQLite3がサポートされており、Appleがそれに追随している。
よってHTML5が完成した暁には、SQLite3は当然サポートされる事であろうと想像（もしくは期待）されている。
ではSQLite3というのが何なのかというと、これは、ファイルと、ファイルを編集するためのツールのセットだ。
イメージとしてはCSVファイルとExcelのセットみたいなもんだと思ってもいい。
長所は無料でオープンソースなこと。例えで言うExcelにあたる部分のソフトがとても軽いこと。
mysqlとかと比べるべきものではない。サーバプロセスという概念は存在しないので、
行ロックはおろかテーブルロックだって無いし、2カ所から同時に書き込みすると片方がコケるか最悪データが壊れる。
比べるならhtmlSQLとかのほうが近いかも。あれは書き込みできんけど。
アンチMSな人にわかりやすく言うと、Accessのmdbのテーブル部分みたいなものです。
技術的な存在意義は、Cookieをリッチにしましょう、という事だと思う。
おそらく排他制御の観点から、ドメイン毎とかパス毎にSQLiteデータベース（１個のファイルです）を作成して、
ファイル毎に1カ所（あるjsファイル）だけから書き込むようにしてね、という実装になるのだろう。
だとすると当然、そのブラウザの当該HTML上のJavaScriptからしかデータは操作出来ないことになる。
ローカルストレージの利点がオフラインブラウズにあるのだとしたら、
そもそもデータベース制御がブラウザ（上の特定ファイル）に縛られる事はデメリットなのではなかろうか？
ネイティブアプリ（言葉がわからん。Windowsのexeのことが言いたい）を不便にする事を目的として、
HTML5の規格の存在感を高める手段としてSQLiteを選んでるなら、それはナシじゃないかなあと。
そんな陰謀論めいた話じゃなくて、単純にSQLiteしか選択肢が無かったとか、
サーバプロセスを規格に盛り込むのは重たすぎるからやめたというのが実情なんだろうけど、
「HTML5が流行るからSQLiteを勉強しなきゃ」みたいな誤解を受ける現状は、ちと可能性を狭めすぎじゃないかなー。
1
1 件中 1 ～ 1 件目
