indexedDB は世界を微救うのかについての生半可な検討

でじゃぶ?

indexedDB は世界を微救うのかについての生半可な検討

なにぃ?

一つ前のを書いてる時から当然目に飛び込んできてる、indexedDB。

初見でね、この回答「オレが書いてやったぜっ」と言ってるこれの意味がわからなくてなぁ。なに、ほんとにこれ「ローカルストレージ」になってんの、てのが、「知らないとわからない」というカラクリ。

あ、これか

そしてワタシは「使い方・書き方」が知りたいわけじゃない。「どこにどのようにストアされ、それはユーザが関与できるのかどうか」だ。のでHTML 5 Web Storage で見たのとおんなじことをやってみる。

少なくとも、なクロスブラウザ問題な件

なんとなく localStorageDB.js が:

1 var indexedDB = window.indexedDB || window.mozIndexedDB || window.webkitIndexedDB || window.msIndexedDB;

てるので、メジャーなブラウザでは使えると思って良さそうだね。バージョン問題はあるにせよ。まぁここら辺は何か調べればすぐに出てくるであろう、それこそ W3CSchools でも言及してるかもね。

エンドユーザにはどう見えるの?

HTML 5 Web storage の 10倍持てちゃうので、手持ちのデータだとなんか面倒だったりするが、まぁやってみるとしますか。

API がどうやら「データベース的」で手続きが結構大変そうなので、だったら「わざわざ key-value ストアに寄せた」localStorageDB.js をそのまま使って検証しちゃうのが早いね:

 1 // ダウンロードして自分のサーバに配備、するほどの大きさでないので、
 2 // localStorageDB.js の中身を上で丸々コピーした、として。
 3 
 4 // 一つ当たり JSON 文字列で 7MB 強。10個書き出せば 70MB 超え。
 5 ldb.set('malrawdata01', JSON.stringify(malrawdata));
 6 ldb.set('malrawdata02', JSON.stringify(malrawdata));
 7 ldb.set('malrawdata03', JSON.stringify(malrawdata));
 8 ldb.set('malrawdata04', JSON.stringify(malrawdata));
 9 ldb.set('malrawdata05', JSON.stringify(malrawdata));
10 ldb.set('malrawdata06', JSON.stringify(malrawdata));
11 ldb.set('malrawdata07', JSON.stringify(malrawdata));
12 ldb.set('malrawdata08', JSON.stringify(malrawdata));
13 ldb.set('malrawdata09', JSON.stringify(malrawdata));
14 ldb.set('malrawdata10', JSON.stringify(malrawdata));

(白状しとくと実はこれから書くことは最初から結論がどうなのか「知ってる」つもりになってる。なぜなら、「F12状態でもう見えてる」んだもん。)

であ:

えーっとそもそもなんだ、「10倍」は既にガセか。70MB がしっぽり入りおったわい。なんだ、既に救世主感出てるがどうしたことか。

ともあれ、

  1. per origin な点は HTML 5 WEB Storage と同じ
  2. F12 れば誰でも見れるのはいいが F12 ないと見れないのは HTML 5 WEB Storage と同じ
  3. 70MB でも余裕で「エンドユーザの許しなく」浪費出来ちゃいますけど、何か?

それでええんか、ええのんか。

なんっか釈然としないところも残るのだが、ただ、ワタシの動機であるところの、「短期記憶から長期記憶へ」というニーズにはばっちり合致してしまうんだよね、こんだけのサイズ使えると。

てことはあれかなぁ、「indexedDB を使ってディスクを使ってます」ということをアプリケーション自身が自分で告白すべし、というノリなのかいね? いいっちゃぁいいのか、いいのか? いいの? いいのね?

もう尻論

釈然としないのは置いといて、「HTML 5 Web Strorage より微かに世界を(特定の意味でのみ)救う」。

ブラウザはもうちょっと頑張って欲しいとは思う。開発者ばかり優遇してはいけない。ちゃんとエンドユーザが「すぐにわかる」ようにしないと。これを WEB アプリケーション開発者だけの責務にしちゃうのは酷だと思う。それほどまでに「インターネットな世界」はダークサイドに溢れているのだから。

2018-02-07追記: Dexie はもっと世界を微救う(一応)

確認したかったことの性質から localStorageDB.js を使ったけど、作った本人が言ってるような「牛刀だから」という理由で Dexie.js を避けたわけではなくて、「手早く本題だけ知りたかったから」ね。

Dexie.js、ドキュメントからも滅茶苦茶簡単に導入出来ることがわかるし、「簡単でわかりやすい」と思う。Hellow World をそのまんま写経:

 1 <!doctype html>
 2 <html>
 3  <head>
 4   <script src="https://unpkg.com/dexie@latest/dist/dexie.js"></script>
 5   <script>
 6    //
 7    // Declare Database
 8    //
 9    var db = new Dexie("FriendDatabase");
10    db.version(1).stores({
11      friends: "++id,name,age"
12    });
13 
14    //
15    // Manipulate and Query Database
16    //
17    db.friends.add({name: "Josephine", age: 21}).then(function() {
18        return db.friends.where("age").below(25).toArray();
19    }).then(function (youngFriends) {
20        alert ("My young friends: " + JSON.stringify(youngFriends));
21    }).catch(function (e) {
22        alert ("Error: " + (e.stack || e));
23    });
24   </script>
25  </head>
26 </html>

ここでの「FriendDatabase」がデータベース、「friends」がテーブルで、"++id,name,age" がカラムの定義をしている(RDBMS の DDL 相当の記述)。これの書き方は Schema Syntax に。auto incremental なキーを使いたければ例のように「++id」ということね。

どこまでが indexedDB の仕様で、どこからが Dexie のテリトリーかはよくわからんけれど、とにかく「ワシらがデータベースに期待するもの」について、結構出来るように思える。(まぁ「SQL 脳」からの脳内変換しようとすると結構疲れる気はするけれど、すぐ慣れろ、きっと。)

というかさすがに join みたいなことは出来ない? 皆考えることは一緒だね。本体ではサポートされてないがプラグインがある、と言ってるのかな。

現実問題として、「データベースに寄せた何かしらインフラ」が「データベース的である」ことを謳っている場合に、普通の RDBMS 経験者は「SQL に似てる! ステキ!」と言うことを期待しているわけではなくて、「リレーショナル」であることの方を期待しがちなんだよね。もちろん「宣言的」に記述出来る「SQL」そのものも使いたいわけだけれども。なのでどんなにそれが「データベースっぺぇ」という見かけをしてても、join して一撃でお取り寄せ出来ないとわかったその瞬間に、途端に残念感が漂うのよね。なのでまぁ「皆同じことを考え」てくれて、「対応してくれる人がいた」ことが幸い。