多次元構造をRDBで表現するのって難しいよね
こちらからのインスパイア。というか思い出したこと。
「今時の組織はSQL不向き? - Ognacの雑感」
http://blogs.wankuma.com/ognac/archive/2009/09/23/181540.aspx
以前、ワークフローエンジンを自前で組んだことがあったのですが、そのときにも大変苦労しました。
組織図ツリーと、ワークフローのリストと。
それぞれ時系列での変化への対応も必要で。
バージョン1はかなりきたないER図になってしまったことを思い出します。
各々のツリー表現と、相互の関係と、そこに使用開始日・終了日をもたせる構造にしてしまったので。
で、当然のごとく処理も重かったと。
（データがたまるとガンガン重くなった）
バージョン2では、楽々ERDレッスンとか読んで勉強した内容を元にER図から見直して、だいぶすっきりした構造にはなったのですが、外的要因によりコードは日の目を見ず。
（一部は活用しましたが）
オブジェクトDBでそのまま永続化できたらいいのになーと思うこともありますが、SQLの非手続き的な振る舞いもとても魅力なのでなかなか捨てられず。
（それとも、オブジェクトDBでもSQL的に集合論的な検索をかけられたりするんでしょうか？？）
◇
まぁ、今ではExcelのシートとかCSVファイルに対してSQLを発行する程度のことしかしてないんですけどね。
ふと思い出したもので。
