A-Listers

サンフランシスコのプログラマLaurie Voss氏が書いた見逃せない記事が賑わっています。近年のフレームワークやライブラリの定番中の定番ORマッパーが既にアンチパターンなのではというのが彼の主張です。この記事を書くきっかけになったのはこのツイートだそうです。

I cannot overstate the degree to which ORM is a dangerous antipattern.—
Laurie Voss (@seldo) June 09, 2011

ORM が危険なアンチパターンだっていうのはどれだけ言っても言い過ぎることはない

このツイートに対して各方面(ActiveRecord, Doctrine, Hibernate)から多くの（激しい）返信が寄せられて書かれたのが問題のエントリです。まずはアンチパターンとは何かの定義として下記の2つを挙げています。

• 当初は有益だが、長期的にみると良い結果以上の悪い結果を招く。
• 確証があり繰り返されている別の解決方法がある。

当初は良さそうに見えたORMがいざ使ってみると問題が明らかになり、しかもその時には切り替えるわけにもいかなくなるというのが彼の主張です。彼による皮肉がたっぷりの論説の最後に付いていたまとめリストは下記のとおり。

• ORMはSQLベースのモデルよりも最初のうちはシンプルで理解しやすく、手早く書く事ができる。
• 効率はどんなプロジェクトでも最初の頃は十分。
• 不幸にもそれらのアドバンテージはプロジェクトが大きく複雑になると消失し、抽象化は破綻し、開発者はSQLを使わなければならなくなる。
• ORMの抽象化はほぼ100％のプロジェクトで破綻する。
• オブジェクトはリレーショナルなクエリの結果を表現するのには不適切。
• 不適切にクエリをオブジェクトにマッピングすることによって、ORMを廃止しない限り簡単には修正できない非効率性がアプリケーションのあちこちにばらまかれる
• リレーションを保存する代わりにORMを全てに適用する場合、設計をよく考える必要がある。
• データが元々オブジェクトならば、NoSQLにオブジェクトを記録する方がリレーショナルデータベースよりも早い。
• データが元々リレーショナルならリレーショナルデータベースに対するオーバーヘッドになるだけ。
• リレーショナルなクエリはモデルレイヤーに隠蔽する。ただしAPIの設計は汎用化の誘惑に打ち勝ってアプリケーションに必要なデータを返すようにする。
• オブジェクト指向設計はリレーショナルなデータを効率的に表現できない。これはORMが解決できないオブジェクト指向デザインの根本的な制限だ。

ORMを使った事がある人にとっては心当たりがありまくりな主張ではないでしょうか。意外と長文なんですが原文を読んでもらう方がORMが良さそうにみえて問題が起こり、そしてその解決方法などのより正確な主張がわかります。また元の記事には現時点で47のコメントが付いており盛り上がっています。
さて、みなさんはORMを次のプロジェクトでも使いますか？

via:http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern

関連:
データベースの間違った使い方10項目 « A-Listers
いきあたりばったりのアーキテクチャと教訓 － Publickey

一般的なシステムで広く利用されているリレーショナルデータベースですが、システムの進化と共にデータベースの構造も複雑になりがちです。RestMQの作者、Gleicon Moraes氏の公開したスライドがシステムが複雑化していく様子をわかりやすく説明した上で「アンチパターン」を提示していました。

それによるとデータベースのアンチパターンは以下の通り。

• 動的なテーブルの作成
• テーブルをキャッシュとして使う
• テーブルをキューとして使う
• テーブルをログとして使う
• 分散したグローバルなロック
• ストアドプロシージャ
• 使われない項目
• JOIN地獄
• ORMによって繰り返されるクエリ
• 負荷のコントロール

どれも理由があって採用されるデザインですが、確かに後に問題を引き起こした経験もあり耳が痛い感じですね。スライド内ではそれぞれの問題についての解決策としてMongoDBやRestMQなどの利用を進めています。「本来の使い方をしていない」という事の例として「レースカーのようにドリフトする鴨の画像」が使われていたのもユーモラスです。

他のページの画像も面白くタメになる内容なのでご覧になってみてください。

via:http://www.slideshare.net/gleicon/architecture-by-accident