オブジェクトの扱いとしてのNoSQL（非・半構造化ＤＢ）とＲＤＢとWindows8と表

たとえば、商品として、
・本
・iPhone
・メンズシューズ
を扱う某Ａ社を想定しよう（いや、某になってない気もするが、気にしない）

このような会社の場合、商品登録・表示が問題になる

　　本に著者はいるが、iPhoneに著者はいない（スティーブ・ジョブス？）
　　iPhoneには、いろいろな契約がある
　　メンズシューズには、サイズとかがある

さあ、どうするか・・・

---

■NoSQL（非・半構造化ＤＢ）とＲＤＢ

これらすべては、商品なので、商品というテーブル（に相当するもの）が必要なのはわかる。

　NoSQL（非・半構造化ＤＢ）の場合、構造ががちっと決まっていないので、本でも、iPhoneでもメンズシューズでも、お構いなしに、属性と値の組を、商品というレコード的なまとまりにして登録できる（というか、登録しないとまずい。ＨＢＡＳＥなどでは、その１レコードが１トランザクションとなるので）。

　一方、ＲＤＢの場合には、共通部分を商品テーブルとして登録し、相違部分をそれぞれ
　　　本テーブル
　　　iPhoneテーブル
　　　メンズシューズテーブル
　として作成する。

　しかし、これらばらばらでは扱いにくいので、Viewをつくり、商品テーブルと、相違部分のテーブル３つを連結させる。（商品テーブルをはじめに書いてLEFT JOIN)。商品のアクセスは、そのViewのDAOを作って行い、セーブは、商品の属性を見て、商品テーブルと相違部分のテーブル（例えば本なら商品テーブルと本テーブル）を更新する形になる。

---

■Windows8と表

では、これを表示することを考える。
　単純にＶｉｅｗを作ったものを表で表示してしまうと、

　　共通部分だけ表示すると、個別情報が消える
　　個別情報を表示すると、本のときIPhoneの欄はいらない→スカスカになる

　なので、実際には、classを使い、表示をＣＳＳなどで切り分ける
　（Ｃｌａｓｓが本なら不必要なiPhoneの枠等は、ＣＳＳで、display: none;にする）

　ということで、表の場合には、非構造化、半構造化データは、いろいろＣＳＳでいじったり
　大変になる

　一方、Windows8は、グリッドが基準になる。
　あるレコードの属性は、タイルっぽくまとめている。ここのタイルが増えようが減ろうが、
そんなに関係ない。
　ということで、非構造データ、半構造データでも表現しやすい（纏めておけばいいから）
ということになる。

---

　ってことで、ビジネスに俊敏性を持たせたい場合は、ＮｏＳＱＬ＋Windows８みたいな「まとめて表示」が楽だったりするんでしょうね。

　最近、ダイバーシティ（多様性）的な価値観に世の中が移りつつあるけど、その場合、非・反構造的なデータの取り扱いが必要になってきて、それに、Windows８の表示などが、あっているのかもしれない。そのような時代にあった言語としては、オブジェクトの属性を柔軟に扱えるJavascriptなんでしょうね。