【ORM不要論の歴史】なぜ生まれ、20年前に何を言われたか

Transcript

1. 2026年9月 ORM不要論を、20年ぶんさかのぼる 第2回 なぜ生まれ、20年前に何を言われたか 赤神 青空
2. 02 なぜORMが生まれたか 2005年ごろの現場を見る 今ココ 歴史 2/14
3. ▪JavaでDAOを手書きした場合（一部） ORMなしで書くとこうなる 中身を読む必要はありません。長いということだけが情報です。 java public User findById(long id) throws SQLException { Connection conn = null; PreparedStatement ps = null; ResultSet rs = null; final String sql = "SELECT id, name FROM users WHERE id = ?"; try { conn = connectionFactory.getConnection(); ps = conn.prepareStatement(sql); ps.setLong(1, id); rs = ps.executeQuery(); if (rs.next()) return mapRow(rs); return null; } finally { if (rs != null) rs.close(); } 今ココ 歴史 3/14
4. ▪国内のJava・.NETで、ある程度の規模の案件では 2005年より前には一般化していた 当時よく使われていたのは Hibernate、iBATIS、S2Dao あたり。以下は、当時を知る書き手の回想として。 DTOのgetter/setterを全部手で書く Connection / PreparedStatement / ResultSet を毎回開いて閉じる 入力補完のないテキストエディタで書いている人も多かった 開発PCが貧弱でIDEを使うほうが遅い、という事情もあった 今ココ 歴史 4/14
5. ▪高尚な設計思想から生まれたわけではない 出発点は素朴だった ORMが世に出てきた経緯は、 「DAO/DTOを手で書くのがめんどくせえ」 だと言われています。 この出発点は、今の「AIが書いてくれるなら要らない」と地続きです。 今ココ 歴史 5/14
6. 03 2006年の論争 The Vietnam of Computer Science 今ココ 2006年 6/14
7. ▪講演ではなく、懇親会の立ち話から始まっている いつ、どこで言われたか TechEd 2004（サンディエゴ）のカンファレンス後のイベントでの雑談に人が集まり、即席のBOFになった。その場で出 た一言が発端。 記事として書き下ろされたのは、その2年後の2006年6月 書くきっかけになったのは、当時の2つの動き ADO.NET 3.0 の entity support の発表 JPA が EJB Entity Beans と JDO の置き換えとして受け入れられたこと つまり最初から、特定の製品ではなく「この方向でいいのか」への疑問だった 今ココ 2006年 7/14
8. ▪Ted Neward「The 20年前に言われたこと Vietnam of Computer Science」（2006年6月） 出だしは順調で、時間とともに複雑になり、やがて抜け出せなくなる。 境界線も、勝利条件も、撤退の道筋も、どこにも定義されていない。 — Ted Neward（原文では "no clear demarcation point, no clear win conditions, and no clear exit strategy"） 今ココ 2006年 8/14
9. ▪上の3つを今回、下の3つを次回に見ていく 原典が挙げている6つの問題 【モデルの構造から来るもの】 継承の写像 同一性 部分取得 どれを選んでも何かを諦める 参照で見るか、状態で見るか オブジェクトは一部だけ持てない 3方式しかない 【運用と組織から来るもの】 別物の基準が違う 半端が作れない スキーマの所有権 二重スキーマ 取得の書き方 開発チームの手を離れて凍結される コードとDDLの両方に同じ知識 どれも一長一短で決着しない 誰のものか 今ココ 2006年 定義が2箇所 QBE / QBA / QBL 9/14
10. ▪原典が最初に挙げている問題 継承の写し方と、関連の写し方 table-per-class … クラスごとにテーブルを作る 派生クラスを1件取るのに、階層の数だけJOINが要る 「Personを全部探す」だけで、派生先の全テーブルにJOINが伸びる table-per-concrete-class … 最派生クラスだけテーブルにする 非正規化のコストを受け入れることになる table-per-class-family … 階層まるごと1テーブル 空の列が大量に出るので、全列をNULL許容にせざるを得ない 原典は、継承の写し方と関連の写し方をひと続きで扱っている 関連先のデータを取るには、結局どこかでJOINが要る いつ取りに行くかは別の問題として、後段で改めて論じられる 今ココ 2006年 10/14
11. ▪クラス階層を、どうテーブルに落とすか 継承の3方式 オブジェクト側 Person テーブル側 table-per-class PERSON Student GraduateStudent 継承は3段 どれを選んでも代償がある STUDENT table-per-concrete-class GRAD STUDENT GRADUATE table-per-class-family PERSON（判別カラム付き） 1件取るのに階層の数だけ JOIN が要る 最派生だけをテーブルにする 非正規化のコスト 階層をまるごと1枚に入れる 全列を NULL 許容に 派生が増えるほど伸びる 同じ列が各所に重複する 整合性制約を自分から捨てる リレーショナルモデルに継承という構造が無いので、写し方は3つしかない 実装が下手だからではなく、モデルの構造がそうなっている 選択肢は3つしかなく、どれも別の代償を払う 今ココ 2006年 11/14
12. ▪「部分取得」から派生する問題（ただし原典の 後から読みに行くとN+1になる N+1 とは別） 最初のSELECTが1本、 user.posts に触れるたびに1本。10人なら11本、100人なら101本。 原典が N+1 と呼んでいるのは列を1つずつ取る話で、いま言う行の N+1 とは別。 ruby users = User.limit(10) users.each do |user| puts user.posts.count end 今ココ 2006年 12/14
13. ▪2006年のエッセイの核心 実装では消えない これらは実装の出来不出来ではなく、 モデルの構造そのものから来ている。 だから解けない 最初の8割を簡単にする代わりに、残り2割で泥沼になる。 だから撤退できない 2割に入った頃にはすでにORM前提で書かれている。 「30年やって撤退を繰り返している」と言われるのは、この部分です。 今ココ 2006年 13/14
14. ▪第3回 次回 運用の問題は、いまの責務論に直結する 構造から来る問題は、実装では消えない。 では残りの3つはどうなのか。 スキーマの所有権と、二重定義の話に入ります。 今ココ おわりに 14/14