O/Rマッパーが悪いのはオブジェクト永続化にRDBを使おうとしたことが悪い

公開日:2018-11-18
最終更新:2018-11-21

完全なるポエムです。多分な推測が混ざっているので、信用しないでください。

データベースとビジネスロジック

かつてのシステム、モノによっては今現在でも、データベースがシステムの中心でした。業務に関連するあらゆるデータをどのようにデータベースに保存するのか、各アプリケーションからデータベースをどのように操作するのかが問題でした。アプリケーションの役割はユーザーの入力に基づいてSQLを作成し、それをデータベースに投げて、結果をユーザーに返すというのがメインでした。

重要なのは中核となるデーターベースであり、アプリケーションは目的によって別々に作成されました。データベースに何のデータをどのような形で保存するのかが最も重要であり、データベース設計がシステムの命運を決めると言っても過言ではありませんでした。

オブジェクト指向とオブジェクト永続化

やがて、Javaを初めとしたオブジェクト指向のブームがやってきました。オブジェクト指向ではあらゆるデータをプログラム上のオブジェクトとして扱いやすくなっていました。しかし、オブジェクトはメモリ上にしか存在しないため、プログラムの終了によってオブジェクトは削除されてしまいます。また、いつまでもオブジェクトをメモリ上に存在させていれば、大量のデータを扱う場合はすぐにメモリ不足に陥ってしまいます。つまり、終了してもなくならない、プログラム上は破棄されてもなくならい、いずれ同じデータがあるオブジェクトを呼び出せるようにする必要があったと言うことです。それがオブジェクトの永続化という問題でした。

単純に永続化するのであれば、オブジェクトをシリアライズしてファイルに保存という手法を使えばできないことはありませんでした。しかし、大量のデータを扱う上で、プログラム上で永続化すべきオブジェクト全てをシリアライズしたファイルを保存しておくには読み込みや書き込みのパフォーマンスに不安があります。そこで、これまでも多くの実績があるリレーショナルデータベース(RDB)をオブジェクトの永続化に使うことを考えました。

自動的なO/Rマッピングを実現するO/Rマッパーの登場

クラスとテーブル、オブジェクトとレコード、プロパティとカラム、これらを1vs1で紐付ければ単純にオブジェクトをRDBのレーコードとして書き込んだり、レコードをオブジェクトとして読み込んだりすることが可能なように思えました。この一見単純そうに見えるオブジェクトのレコードの紐付けこそがO/Rマッピングです。また、クラスのメソッドの実装として、一つ一つSQL文を書くこと自体が手間であり、ほとんどの場合は似たような書き方になってしまいます。そこで、O/Rマッピングを自動的に行うためにO/Rマッパーが登場しました。

O/Rマッパーは保存や検索などO/Rマッピングにおいてよくある操作に対して、SQL文を自動に生成し、RDBからのデータを自動的にオブジェクトへ変換してくれるというものでした。プログラマーは似たようなSQL文を何度も書かなくても、オブジェクトの永続化ができるようになりました。

O/Rマッパーの限界

しかし、それで全てがうまくいったわけではありません。オブジェクト指向とRDBは全く設計思想が異なり、データ構造も似て非なるものです。その差異(インピーダンスミスマッチ)を吸収するためにO/Rマッパーは複雑になり、また、吸収できなかった部分が制限として残り、やがて発行されるSQL文を理解せずにはO/Rマッパーを使いこなすことはできないことに多くの人が気付きました。

例えば、N+1問題はその最もたるものでしょう。O/Rマッパーがどのようなモノであるのか、どのようなSQL文をクエリするのかを理解せずに、単なるオブジェクト永続化としてしかみていない場合、素直に書いたコードはN+1のクエリを行うことになってしまうでしょう。

RDBを使うという発想自体の間違い

O/Rマッパーが悪いのでしょうか?では、O/Rマッパーを使わずに、SQL文を一つ一つ書いて、一々オブジェクトへの変換をすれば解決する問題でしょうか?いいえ、そうではありません。間違いは最初の時点にあったと考えています。それは、オブジェクトの永続化にRDBを使うという発想です。その間違った発想こそがオブジェクトとレコードを紐続けるO/Rマッピングという愚直な発想を招き、それを実現するO/Rマッパーというものを産み出してしまったのです。

RDBを使いこなすのであれば、DBはデータの集合体であるDBのままとして扱った方がRDBの利点を生かせたはずです。それを無理にオブジェクトへ変換してしまうから無理が生じるのです。単なる変換ではいかにもできそうであったため、そうしてしまったのでしょうが、それではRDBの利点をかき消してしまうし、それらの利点を生かそうとしてしまうと、複雑怪奇なコードになってしまうことでしょう。

O/Rマッパーはオブジェクト永続化にRDBを使うにあたって便利になるように作ったはずですが、O/Rマッピング自体が型に合わないものを無理矢理はめ込むような作業であるため、複雑さが増し、使いにくく、そして、中途半端なものになってしまったのです。

RDBからNoSQLへ

どうしたらよかったのか?それは、簡単です。オブジェクト永続化にRDB以外を使うと言うことです。いわゆるNoSQLというものです。ただ、NoSQLにも色々あり、そのままオブジェクトを保存することを目的としたオブジェクトデータベースもあれば、XMLやJSONといったドキュメント指向データベースなど、様々です。また、RDBとの歴史の差を考えると、まだ市場の信頼を得ているとは言い難く、どれが一番いいのかは私にはまだ判断つきません。それでも、これからはO/RマッパーをRDBと一緒に捨てて、オブジェクト永続化にはNoSQLを使うことが主流になっていくのではないかと思っています。

ただ、勘違いして欲しくないのはRDBがなくなるというわけではありません。最初に言ったとおり、データベースをシステムの中核と考えるのであれば、今でもRDBは優れた選択の一つです。しかし、ビジネスロジックとなるアプリケーションでO/Rマッパーを使うという愚かな選択は無くなっていくと思います。SQL文を直接書かず、RDB製品間の差異を吸収したいというのが出るとしても、LINQのようなものになっていくのではないでしょうか。

いずれにしても、O/Rマッパーは時代と共に消えゆく運命なのでしょう。

記事が少しでもいいなと思ったらクラップを送ってみよう!
72
+1
@raccyの詩集

よく一緒に読まれている記事

0件のコメント

ブログ開設 or ログイン してコメントを送ってみよう
目次をみる

技術ブログをはじめよう

Qrunch(クランチ)は、ITエンジニアリングに携わる全ての人のための技術ブログプラットフォームです。

技術ブログを開設する

Qrunchでアウトプットをはじめよう

Qrunch(クランチ)は、ITエンジニアリングに携わる全ての人のための技術ブログプラットフォームです。

Markdownで書ける

ログ機能でアウトプットを加速

デザインのカスタマイズが可能

技術ブログ開設

ここから先はアカウント(ブログ)開設が必要です

英数字4文字以上
.qrunch.io
英数字6文字以上
ログインする