これも業務中にあって悩んだことなのだが、データベースアクセスの実装方法を選択する際、「ORMapper を使うべきか、それとも生の SQL を書くべきか」という判断に迷ったことがあった。

そこでまた復習がてら、ORMapper を効果的に活用できる場面と、逆に避けた方が良い場面についてを、調査し書き起こしておこうと思う。

ORMapper とは

ORMapper（Object-Relational Mapper）は、リレーショナルデータベースのテーブルとオブジェクト指向プログラミングのクラスを橋渡しするツールである。代表的なものとしては、Python の SQLAlchemy、Typescript の Prisma などと言った様なものがある。

ORMapper を使うべき場面

まずは ORMapper を使った方がいい場合についてを記載する。

• 標準的な CRUD 操作が中心の場合

基本的なデータ操作（Create, Read, Update, Delete）が主な処理の場合、ORMapper が効果的な事が多い。

• オブジェクト指向設計を重視する場合

ORMapper はデータベースのテーブルとアプリケーションのオブジェクトを直接マッピングするため、オブジェクト指向プログラミングの利点を活かした設計が可能。

チームメンバーの SQL スキルにばらつきがある場合でも、オブジェクト操作をするのみなので有用である。

また、ドメイン駆動設計（DDD）を採用している場合や、ビジネスロジックをオブジェクトとして表現したい場合にも有効である。

• メンテナンス性を重視する場合

ORMapper はデータベース操作を抽象化するため、コードの保守性が向上し、変更が容易になる。

また、ORMapper はスキーマの変更を容易に扱えるため、柔軟なデータモデル管理が可能である。

• データベースの移行可能性がある場合

ORMapper は異なるデータベースを抽象化して統一的に扱えるため、将来的な DBMS 変更の可能性があるなど、複数のデータベースを利用する場合にも有用である。

ORMapper を避けるべき場面

逆に、ORMapper を避けた方がいい場合についてを記載する。

• パフォーマンスが非常に重要な場合

ORMapper はデータベース操作を抽象化するため、クエリの最適化が難しくなり、特に複雑なクエリではパフォーマンスが低下する可能性がある。

• 非常に複雑なクエリが必要な場合

複雑な SQL クエリやカスタムクエリが必要な場合、ORMapper の抽象化レイヤーがかえって邪魔になることがある。

• 大量のデータを処理する場合

大規模なデータセットを処理する場合、ORMapper が生成するクエリの効率が低下し、メモリ使用量が増加することがある。

• 特定の SQL 機能やデータベース固有の最適化が必要な場合

ORMapper はデータベースの特定機能を完全にサポートしない場合があり、カスタマイズが難しいことがある。

特にレガシーシステムの場合は既存のストアドプロシージャを使用する場合や特殊なデータベース構造との互換性が必要なことがあり得るため、適さない場合もある。

ハイブリッドアプローチ

実際のプロジェクトでは、ORMapper と生 SQL を組み合わせて使用することが効果的な場合が多い。

---

ORMapper の使用判断は、プロジェクトの要件、チームのスキルセット、パフォーマンス要件、将来的な拡張性など、多くの要因を考慮して行う必要がある。

ORMapper と生 SQL どちらかのみで利用しなければならないというものではなく、両方用いてそれぞれの長所を活かせる場面で適切に使い分けるのも一つの策である。その点も念頭に入れて決定しよう。