« 仕様変更にも良し悪しがある | トップページ | 文章術:「改行」を自覚的に用いる »

2017.04.14

ORマッピングの功罪

 オブジェクト指向にもとづくクラス構造を、本来異質なRDBのテーブル構造に対応させることをOR(Object-Relational)マッピングといい、そのための仕掛けがORマッパーである。代表的なものがHibernateやJPAで、これらを使うことは、WEBアプリ界隈では常識といっていいものになっている。しかし、これを業務システム開発で利用するのは、特別な事情がない限りお勧めできない。

 ORマッピングの技術は良いものと悪いものとをもたらした。良いものとしては、Ruby on Railsのような生産性の高い開発環境を挙げられる。じっさいRailsは、TwitterやGithubといった優れたサービスの基礎として社会に貢献した。いっぽう、業務システム開発の世界に対しては、ORマッパーはどちらかといえばハタ迷惑な影響ばかりをもたらしたと言わざるを得ない。テーブル構成が比較的単純に済むWEBアプリを開発するためにはたしかに効果的なのだが、テーブル数がふつうに100個を越える業務システムではむしろ足を引っ張る。

 どういうことか。「フィールド数のメトリクス」でも説明したが、ふつうに設計されたDBでは、少なくとも半数のテーブルが複合主キーをとる。ところが多くの場合、ORマッパーを基礎とする開発環境では、複合主キーの使用が非推奨なのである。これはオブジェクトが、暗黙的に付与されるオブジェクトIDで識別されることに関係している。その結果、DBに含まれる半数のテーブルについて、通常の設計の他に、ORマッパーに合わせて「正規化崩し」したテーブル定義を管理せざるを得なくなったりする。つまり、複合主キーを含む「論理設計」と、「id」を単独主キーとする「物理設計」とを併行管理する羽目になる。

 結果的に、システム仕様の管理コストが急増する。正規化崩しというものは、せいぜいレスポンス確保のための「最後の手段」としてやることだ。それを、開発環境自体の都合でやらねばならないとしたら、開発環境としてスジが悪すぎる。しかも、「テーブルのレゾンデートル(存在意義)」と言うべき主キーを改変しなければならないのはほんとうにつらい。

 もうひとつの弊害として、育成上の悪影響を指摘できる。キャリアの初期にORマッパーを用いた開発を繰り返すことで、新人技術者が「複合主キーなしでDB設計は可能であり、そのほうが合理的である」と勘違いしてしまう怖れがある。その結果、単独主キー(id)のテーブルしか想像できなくなって、まともにデータ設計できない技術者として成熟してしまう。「関数従属性?正規化?ユニーク制約?なにそれオイしいの?」みたいになる。

 悪いことに、複合主キーを用いた端正なDB設計になかなかお目にかかれないのが実情である。キー項目がいつの間にか増えたり、やたらと多くの項目が無駄に複合されていたりする。そんな設計ばかりに触れていたら、「複合主キーなんてロクなもんじゃない」と感じてしまうのも無理はない。的確にDB設計するために複合主キーは必要だが、稚拙なDB設計にも複合主キーがふつうに現れる。それゆえこれを用いることの意義がなかなか理解されない。

 とはいえ、「複合主キーを使ってDB設計することが難しすぎるから、もう全部idにしてしまおう」などと考えてはいけない。それは、「構造計算なんて面倒なことはやめて、鉄筋の本数を1本とか10本とかの固定にしてしまおう。柱ごとに鉄筋の本数が違っていたりすれば、施工ミスを引き起こす怖れもあるじゃないか」と主張するようなものだ。もともとDB設計というものは高度な専門性が要求されるエンジニアリング分野であって、技術者がその困難から逃げてはいけない。

 ORマッパーがもたらす三つめの弊害。それは、JavaとかRubyといった汎用プログラミング言語で個別案件をナイーブに開発するやり方が是認され、技術革新の足かせになってしまうことだ。そもそもオブジェクト指向言語を使って作るからこそ、ORマッピングを考える羽目になる。ザリガニ指向言語でゴリゴリと書けば、ZRマッピング(ザリガニとRDBの対応づけ)や、ZRインピーダンス・ミスマッチに悩まされるだろう。「端正なザリガニ構造をがんばってプログラミングしても、誰もその価値を認めてくれない」なんて悩みも出てきそうだ。

 業務システム開発における汎用プログラミング言語の使いどころは、そこではない。規定様式で仕様を記述するだけ(つまり設計するだけ)で業務システムとして動作してくれるDSP(ドメイン特化プラットフォーム)を作る。そのためにこそ使うべきだ。DSPそのものの開発に使うのは、オブジェクト指向言語でもザリガニ指向言語でもいい。DSL(ドメイン特化言語)で個別案件を記述する開発者は、どのみちオブジェクトやザリガニを意識する必要はないからだ。それらの言語特性を隠蔽して、開発者がドメインの特性のみに集中できるようにする――そのための枠組みがDSLで、これを使えば、ORマッピングもZRマッピングも要らないのである。

このブログでの関連エントリー
アンチパターン「成長する主キー」
ナチュラルキーを主キーにしてはいけない

|

« 仕様変更にも良し悪しがある | トップページ | 文章術:「改行」を自覚的に用いる »

コメント

おっしゃるとおりですね。最近若い技術者にDB設計と実装をやらせているんですが、やたらとIDカラムが多くあります。話を聞くと、実装で使用するフレームワークの制約からIDを定義しているとのこと。業務で使うキーはインデックス定義で代替している。
ERが老体SEには苦痛です。

投稿: 盛田智己 | 2017.04.14 11:37

盛田さん

idばかりがPKになっているDB設計ほどハタ迷惑なものはありませんね。そういう理不尽な制約を持つフレームワークなんて、業務システム開発では使うべきではないんです(><)

投稿: わたなべ | 2017.04.19 13:31

フレームワークの設計者から見ると、どぶんの上にどんな業務が乗っかるか分からない前提で作ると、こうなるんでしょうね。
フレームワーク側で、業務キーとフレームワークキーの定義情報をもてればいいんだろうけど。
私も過去にERツール屋さんが業務DBを設計した結果を見たり、CRMパッケージ、PDMパッケージを見た時、いづれもPKEYは1個でした。

投稿: 盛田 | 2017.04.19 14:19

ERツール屋さんに所属する技術者にも単独主キーで設計する悪習が広がっているんですか。なんとも痛ましい。まあそもそもERルール屋さんはツールを売るのが商売であって、DB設計のプロではありません。刀鍛冶に剣術の腕を期待するのは間違いなのでしょう。

CRMやPDMのように業務限定ならテーブル数は少なく済むので、単独主キーでもやりきれるでしょうね。しかし、それらは完結した「業務システム」ではありません。テーブル数が50個を超えるような案件であれば、単独主キーだけでは破綻します。

投稿: わたなべ | 2017.04.24 08:00

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/87674/65147982

この記事へのトラックバック一覧です: ORマッピングの功罪:

« 仕様変更にも良し悪しがある | トップページ | 文章術:「改行」を自覚的に用いる »