OOとDOAの周りでいつもの井戸端会議。

nouvellelune @nouvellelune

@twtshi @pokarim @foobardam 疎行列について何も知らないのですが、「共通部分が非常に少ない」という意味合いですか？

しゅわみ @twtshi

@nouvellelune @foobardam @pokarim 最近グラフ可視化ソフトを使ったのですが，二項の関係がそのまんまグラフとして描画されて感動しました。

しゅわみ @twtshi

@nouvellelune @pokarim @foobardam スカスカの行列です。自然現象の離散モデルは近接する空間だけを考えることが多いのでスカスカの行列が現れがちなのです。

nouvellelune @nouvellelune

@twtshi @pokarim @foobardam wikipedia で読んで、ゼロがやたら多いということだけ理解しました

しゅわみ @twtshi

@nouvellelune @pokarim @foobardam ゼロだらけであっても行列で書くメリットがあるのです。一般化，抽象化です。

pokarim @pokarim

@nouvellelune @twtshi @foobardam RDBでは複数の表というのがメタ構造で、具体的にどんなカラムを持つどんな表があるのか、またカラムにどんな値が入りうるかを決めるのがスキーマになります。言われている構造というのはおそらくスキーマのことだと思います。

pokarim @pokarim

@nouvellelune @twtshi @foobardam 一見スキーマを持たなくても、それを扱うプログラムの側で暗黙的にあるスキーマを想定している場合もあります。一方もちろん完全に任意のXMLを扱うことを想定したプログラムもあります。

pokarim @pokarim

@nouvellelune @twtshi @foobardam 明示的にスキーマを持っていないとしても、業務アプリのバックエンドとしてXMLDBを扱う場合に、全く任意の形のXMLが入りうるような使い方は、officeの文書をそのまま格納するような場合以外あまり考えられません。

pokarim @pokarim

@nouvellelune @twtshi @foobardam また、頻繁に想定されるスキーマが変わるために、プログラム側で暗黙にスキーマを想定していても、そのスキーマをDBMS側に持たせたくないという場合も考えられます。

pokarim @pokarim

@nouvellelune @twtshi @foobardam 構造を持たないデータということで以上のようなことを考えてみましたが、構造を持たないデータということで想定されていたデータはどんなものでしょうか？

pokarim @pokarim

@twtshi @foobardam @nouvellelune 極端な話しですが、任意のRDBデータを表現できるXMLスキーマや、任意のXMLを表現できるRDBスキーマを作ることができますよね。

pokarim @pokarim

@twtshi @foobardam @nouvellelune なので、使いやすさやパフォーマンスの問題を、ある程度具体的なユースケースを考えて議論する必要があると思います。

pokarim @pokarim

@twtshi @foobardam @nouvellelune それはスキーマの有無、XMLDBかRDBかという議論のどちらにも言えることだと思います。

nouvellelune @nouvellelune

@pokarim @twtshi @foobardam スキーマを事前に定義する(RDBで言えばテーブルを設計する)というやり方に限界があると思います。実際は保存時ではなく、取り出すときに型が定まっていれば十分ではありませんか？

nouvellelune @nouvellelune

@pokarim @twtshi @foobardam 「元ネタ(素材)はなるべく加工しないで保存し、取り出すときに必要な形を与える」というアプローチで考えれば、RDBやらXMLDBといった分類はあまり意味をもちません(モデルレベルの話であって物理的な制約はとりあえずおいとく)。

pokarim @pokarim

@nouvellelune @twtshi @foobardam 事前スキーマ定義が問題で、RDBかXMLDBかは問題ではないということはわかりました。元ネタ、というのは例えば業務アプリにおける画面からの入力情報、といったことで会ってますか？

nouvellelune @nouvellelune

@pokarim @twtshi @foobardam 同一スキーマが時系列で変遷していく場合もあるでしょうし、違う進化を遂げてきた同種のデータをまとめる(企業合併で業務データ統合する)ようなこともあるかと。このへんは特定のシナリオにそって考えているわけではありません

nouvellelune @nouvellelune

@pokarim @twtshi @foobardam ビューのような仕組みが(RDBを離れて)もうちょっと自由に使えればなあ、と思うんです。

pokarim @pokarim

@nouvellelune @twtshi @foobardam なるほど、なんとなくわかってきたきがします。入力された情報は、ひとつの事実としてそのまま保存しておき、取り出す際ビューの側で構造変換をおこなう、という感じでしょうか。

pokarim @pokarim

@nouvellelune @twtshi @foobardam ただ、それならばビューと取り出す際の構造変換が強力であれば済む話で、スキーマの変遷があった場合は、古いスキーマを残して新しいスキーマを追加するなど、より柔軟なスキーマの扱いができれば構わない気がしますが。

pokarim @pokarim

@nouvellelune @twtshi @foobardam 表形式に縛られない柔軟で強力なビューが欲しいというのは同感です。

nouvellelune @nouvellelune

@pokarim @twtshi @foobardam まあ、言ってしまえばそういうことですけど、やればやるほど問い合わせ言語の設計/利用が難しくなりそうです(性能は技術の進歩である程度なんとかなるでしょう、と無責任に考える)。