RDBMSへの不満(3)
不満ばかり言っていてもしょうがない。
そんなことはわかっている。
とにかく、これまで実際に
Zopeのオブジェクトデータベース、
DjangoのO/Rマッパー、SQLAlchemyのO/Rマッパーなどを使って開発を経験した中で、
いったいどこが、どういうふうに不満と感じたのか。
とか、XML Databaseを使おう、とかO/Rマッパーを使おうという流れに対して、いったい何が不満なのか。
では、おまえはどうしたいんだ？
というあたりを書いていこうと思うんだけど、
いったい何から書こうか。
思いついたとこから
整理してから書こうとすると、いつまでたっても書けないので、思いついたところから書く。
RDB O/Rマッパー XML Databaseに対して感じるのは、
「（集合以外の）構造についての扱いがない。」という点。
もちろん、全く無いわけではなくて、RDBなら集合、XML Databaseならツリーといった構造はある。
あるけれど、そういった構造と、実際にアプリを作ろうとするときに必要なデータ構造は、普通違う。
ある程度大きいアプリを作ろうとすれば、データ構造が、単一のツリーですむとか、いくつか集合があるだけ、ということはない。
会社があって、その下に部署がツリー構造に存在していて、その下に社員がある。それぞれに、部署名とか社員名とか名前の属性その他がある。これくらいだったら、ただのツリーだ。
XMLであらわすのにそんなに問題は無い。RDBでもそんなに問題は無さそうに見える。
会社テーブルと、部署テーブルと、社員テーブル。あとは適切なカラム。
会社コードとか部署コードを作って、それをキーにしよう。
あとは外部キーと参照整合性制約でばっちり。
そうだろうか。部署は、部署同士でツリーとなる。つまり「なんとか事業部」の下に
「なんとか営業部」があって、そのさらに下に「なんとか課」がある。そんな構造にしたいとする。
普通は、部署テーブルに主キーとしての部署コードと、その部署が所属する部署の部署コードを外部キーとしてもつ。
rootになる部署の所属部署には、Nullでもいれておけばいい。
大体こんな感じだと思う。
こうすれば、各部署が、いずれかの部署の下にある（もしくはrootである）ということが表現できる。（階層の深さが不定で、事業部テーブルと「部テーブル」「課テーブル」と3つのテーブルにわけるわけにはいかないとする。）
図1
｜部署コード（主キー）｜所属部署コード（外部キー）｜部署名 ｜
｜１ ｜Null ｜hoge事業部｜
｜２ ｜１ ｜営業部 ｜
｜３ ｜２ ｜営業１課 ｜
｜４ ｜２ ｜営業２課 ｜
これで、
図２
hoge事業部
└─営業部
├─営業１課
└─営業２課
こんなかんじのツリーが表現できると思う。
ここまでなら、簡単だし、シンプルだ。
でも、ここですでに問題がある。（もちろん問題かどうかは見方による。僕にはあるように思える。）
図1を見ただけでは、それがツリーになっているかどうかは明白ではない。
（もちろん部署名とか所属部署っていうカラム名、もしくは実際のデータを見れば、そりゃわかるけど。）
「あるテーブルのレコードが、自分が所属しているいずれかのレコードへの参照をもっている（もしくはNullでもっていない）。」
というところまでは、自明だ。
だけど、これだけでは、このテーブルを設計した人が、ツリーを表現したかったのかどうかわからない。もしかしたら、順列を保存したくて、リンクリストを表現したかったのかもしれない。
図３
部署をツリーで表してそうとしているなら、図３のような循環したデータは、矛盾した間違ったデータで、こんな状況は存在するべきではない、ってことになると思う。
けれど、図1を見ただけではそんなことはわからない。
（続く）
