【SQL】ORMにおけるクエリマッパーのデメリット

ORMには、主に以下の2点の機能があり、非常に便利なツールである。

機能	説明
ObjectMapper オブジェクトマッパー	取得したDBのデータを特定のクラスなどにマッピングし簡単にオブジェクトとして使えるようにする
QueryMapper クエリマッパー	メソッドチェーンのような書き方で、SQL相当の記述を行うことができる

このうち、チーム開発において「クエリマッパー」の機能だけは気軽に使わないで欲しいということを主張したいと思う。

クエリマッパーを導入することによる不都合

「クエリマッパーを学習するコスト＞ SQLを学習するコスト」だと筆者は考えている。
これは総合的な学習コストについて述べている。

学習コストが高い理由としては、多くのWebエンジニアにとって 色々なデータベースのSQLを学習するより、色々なクエリマッパーを学習する比率の方が多くなりがちであるからだ。

データベースは規模や用途によって、ほぼ1,2個に使うものが限定される
1. 例：無料かつ大規模になっても耐えうるデータベースは、現状ほぼMySQL一択
DBを参照するシステム構築には様々なプログラミング言語の選択肢が存在する上に、プログラミング言語ごとに複数のORMが存在する
1. APIを作るとしても、TypeScript、Java、Ruby、PHP、Go、Pythonなどが選択肢にあがる
2. Node環境のORM一つ取っても、TypeORMやPrismaなどの複数の選択肢が存在する

職場やプロジェクトが変わった場合、
使ったことがないDBを触る確率より、使ったことがないプログラミング言語を触る確率のほうが圧倒的に高いというのは
多くのエンジニアが経験していることではないだろうか。

システムの保守運用をしていく中で、
データベースを別のものに置き換えるというプロジェクトはごく稀である。

一方で、プログラムを刷新するというプロジェクトはそこそこ発生する。

移行作業	サービス停止（メンテナンスモード）の必要性
DB	必須
DB以外のプログラム部分（APIなど）	不要なケースがほとんど

という特性があるため、DBの移行作業というのは意思決定されづらい。

つまり、「DBをスイッチングしても、SQLの修正が不要である」という意見に対しては
「確かにそれはメリットではあるが、その恩恵を受けるタイミングはほぼない」と伝えたい。

プログラミング言語の刷新などを考えると、むしろSQL文がそのまま書かれていたほうが移植しやすいだろう。

とはいえ、時にはDBをスイッチングするケースは全く発生しないということはない。

ただし、この場合でもクエリマッパーによる恩恵を受けることはない。

DBをスイッチングする目的は

に集約されると思うが、どちらの場合でもテーブル構成を変えることを余儀なくされる。

将来的なデータ量の増加を読み切れていない、もしくはパフォーマンスに影響があるテーブル構成になっている可能性が高い。

このようなケースでは「移行時（もしくはその前後に）テーブル構成を見直す」ことこそが根本解決に繋がる。

クエリマッパーは深く考えずに利用してしまうと、N+1問題のようなパフォーマンス悪化のパターンを引き起こしやすい。

また、「テーブルAとテーブルBをJOINすれば良い」というケースでは、
うっかりしていると内部的に「テーブルCを元にテーブルAとテーブルBをJOIN」してしまうことがある。

これらを回避するためには、結局のところDBの特性やSQLの特性について理解しておく必要があり「SQLを覚えなくて良い（SQLの学習コストが低い）」ということにはなり得ない。

ここまでクエリマッパーについての不都合を伝えてきたが、クエリマッパーに限らず技術選定における筆者のスタンスは適材適所である。

これまでの不都合が目立たないケース、つまり以下のようなケースでは
むしろクエリマッパーは効果を発揮すると言えるだろう。

ORM利用の際は、クエリマッパーのデメリットについて理解しておくと良い。

また、オブジェクトマッパーの機能についてはデメリットがないので ORMそのものは導入価値が非常に大きいと筆者は考えている。