RDBのR
デブサミでid:habuakihiroさんのお話を聞いて参りました。時間が足りないなあ・・・・最後の話をもっと突っ込んで聞きたかった。
Activity Based Data Model、略してABD。あれは凄いですよ、まさにラディカル。エンティティからFKを排除ってのが「過激な」と云う意味であり、だがしかしそれがコッドとチェンへの回帰でもあると云うのが「根源的な」と云う意味であり、radicalの2つの意味をきっちり網羅。
世の中、根源的であろうとすれば実は過激だったりするのはまあよくある話で。ファンダメンタリスト。
出だしで、RDBのRをリレーションシップとしてある本がもしあったら焚書せよってな話がありましたが、この大間違いを逆手に取ったのがABDなんじゃないかと。
だって、リレーション同士のリレーションシップを、コッドのドメイン同士のリレーションに置き換えた形になってるじゃないですか。RDBのRをリレーションシップにしてる。
って資料が無い人には何云ってんだか判んないですよね。へへーだ。
とは云え疑問点もありまして。
正規化崩し？
例で売上見出し-売上明細の親子構成と、本来はそれぞれの属性になるFKを「売上関連」に全部外出しにしてますが、そうすると「売上関連」は明細の数だけ出来る訳です。そうすると元々見出しのFKであった顧客IDが重複する事になって、正規化違反になるんじゃないか、と。
これは業務のアクティヴィティと1:1対応する事を優先して、敢えて正規化を崩してるのかな。
うーん、やっぱり「売上見出し関連」と「売上明細関連」と2つ作った方がしっくり来そうな。じゃあ今度はその「売上見出し関連」と「売上明細関連」の間の依存関係を、とか始まって外出しテーブルだらけになりそうな気も・・・。
実際どうなのよ
考え方としてとてもワクワクしますし、実に根源的であり、FK外出ししてみたらそれが業務のアクティビティに綺麗に対応する面白さも判るのですが、その事で何が嬉しいのかと云う点が、時間が無かったのかいまいち伝わって来ませんでした。
例えば。UI上で売上明細の内容を更新しようとします。UI上では明細本来の属性である「数量」も、属性ってよりかはリソースへの依存にすぎない「商品ID」も、同じように更新したいのが人の性でしょう。
そうすると、「数量」と「商品ID」の両方を更新しようとした場合、その1トランザクション内での更新対象となるテーブルが「売上明細」と「売上関連」の2つに増える事になります。
このコスト増大が気にならない程のメリットってのが聞きたかったです。自分で考えたんだけど、頭で考えてもなあ・・・。遺憾。
