日報 #89 - 階層構造とRDBとコミュニケーションと

今日のお気づき。

階層構造をリレーショナル・データベースで表現する時のベスト・プラクティスについて調べておりました。
ノードテーブルとカテゴリテーブルを作って親子関係を記述していく隣接リストモデルはアンチパターンのようです。
入れ子集合モデルがよいとされているようですが、まぁ結局、利用用途に応じて柔軟な対応が必要なのは世の常でしょうね。
http://www.geocities.jp/mickindex/database/db_tree_ns.html
上記のサイトがクッソ勉強になりました。

ところで。

データの保存の仕方1つで「簡単に出来そうなこと」が出来なかったりするのはとても興味深いですね。
別に今回が直接的にそのケースというわけではないですが、
Redshiftを触っている時も、NoSQLを調べている時も思っていたことです。
コンピュータに出来なくて、人に出来ること、みたいな議論をする時に直感的に注目されるのは処理スピードやアルゴリズムの方だと思いますが、
それに加えて、「データの保存方法の違い」という観点を導入する余地もあるのでしょう、きっと。

で思い出したのが、線形代数です。
あれって、問題としている行列に対して、ひたすらベストな基底を発見して、それに向けて世界を書きなおそうぜ！みたいな話じゃないですか。
要は「この状態で計算するとどえらいことになるから、都合のいい世界に写像して、都合のいい計算にしちゃおうぜ」的な感じだったと思うのです。まぁ細かいことは置いといて。
正規化とか、標準系とかも同じような考え方ですよね。
結局、データの表現方法によって演算効率が変わってくるよ、と。

そうなってくると気になる点は2つです。
「表現方法によらない、本質的なデータという概念はあるのか」ってことと、
「ある表現が選択されている必然的理由はあるのか」ってことです。
前者は実在論みたいな話なので、恐らく「そんなものねぇよ、相対的だから全部」みたいな話で決着つきそうです。
で、後者は恐らく「データがおかれた環境に適応した結果だろ」みたいな自己組織化、進化論的な話で決着つきそうです。
すると、「実存がなく、環境ごとに勝手に最適化して形作られている情報」とやらを共有しあうというのが人間のコミュニケーションなわけです。コンピュータは少なくとも後者が完璧に同期されていますが、人間同士は鬼のようにバラバラなわけですよね。
そりゃぁある人にとって「簡単に伝わりそうなこと」が、また別の人にとって「あまりにも困難」ということはあるわけです。
言葉や図というものの本質的な役割は、データの保存状態の同期のようにすら見えてくるわけです。
処理能力の差によるディスコミュニケーションなんて事態よりずっと前の方に、このレベルでの共有が重要のように思えてきませんか。きませんね。

さて、僕が何を言いたかったのかというと。
人同士の情報伝達で重要なのは、
ロジックや伝達スピードとかよりも、
議論の対象になっている情報の「保存のされ方」について説明を尽くすことなんじゃないかなってことです。
あ、現場からは以上です。