☰

ORM またはプレーン SQL を使用していますか? [closed] 質問する

tag-icon • tag-icon sql language-agnostic orm
ORM またはプレーン SQL を使用していますか? [closed] 質問する

私が開発した（その後忘れ去った）アプリのいくつかでは、主にMySQL用のプレーンSQLを書いていました。PythonではORMを使用していましたが、SQLアルケミー、私はそれらを長く使い続けませんでした。たいていの場合、私を妨げていたのは、ドキュメントか複雑さのどちらかでした（私の観点から）。

私はこう考えています: 移植性のために ORM を使用し、1 種類のデータベースだけを使用する場合はプレーン SQL を使用します。データベース サポートが必要なアプリを開発するときに、ORM と SQL のどちらを使用するかについてのアドバイスを本当に求めています。

考えてみると、ORM を使用するよりも、軽量のラッパーを使用してデータベースの不整合を処理する方がはるかに優れています。

ベストアンサー1

Hibernate、EclipseLink、Toplink、OpenJPA などを含む JPA (Java Persistence API、基本的には Java/J2EE/EJB の標準化された ORM API) にかなりの時間を費やしてきた者として、私の観察をいくつか共有したいと思います。

  1. ORM は高速ではありません。十分な性能を発揮し、ほとんどの場合は問題ありませんが、高ボリュームで低レイテンシの環境では、ORM はお勧めできません。
  2. Java や C# などの汎用プログラミング言語では、動作させるには非常に多くの魔法が必要です (例: Java でのロード時のウィービング、インストルメンテーションなど)。
  3. ORM を使用する場合、SQL から遠ざかるのではなく (それが目的のようです)、ORM でパフォーマンスの高い SQL を生成するために XML や注釈/属性を微調整するのにどれだけの時間がかかるかに驚くでしょう。
  4. 複雑なクエリの場合、代替手段は本当にありません。JPA の場合と同様に、生の SQL では単純に不可能なクエリがいくつかあり、JPA で生の SQL を使用する必要がある場合は見栄えがよくありません (C#/.Net には少なくとも動的型 (var) があり、これはオブジェクト配列よりもはるかに優れています)。
  5. ORM を使用する際には、非常に多くの「落とし穴」があります。これには、意図しない、または予期しない動作、データベースへの SQL 更新機能を組み込む必要があるという事実 (JPA ではデフォルトですべてをキャッシュするため、直接のデータベース更新をキャッチしないため、JPA の refresh() または同様のメソッドを使用することにより、直接の SQL 更新を実行することは一般的な本番サポート アクティビティ) が含まれます。
  6. オブジェクトとリレーショナルの不一致は常に問題を引き起こします。このような問題では、複雑さと抽象化の完全性の間でトレードオフが発生します。時には、JPA が行き過ぎて、複雑さの影響が抽象化によって正当化されない、真の収穫逓減の法則に陥ったように感じることもありました。

もう少し説明が必要な別の問題があります。

Web アプリケーションの従来のモデルは、永続層とプレゼンテーション層 (間にサービス層やその他の層がある場合もありますが、この説明ではこれら 2 つが重要です) で構成されます。ORM は、永続層からプレゼンテーション層 (つまり、エンティティ) まで、厳密なビューを強制します。

より生々しい SQL メソッドに対する批判の 1 つは、1 つのクエリで使用されるすべての VO (値オブジェクト) または DTO (データ転送オブジェクト) が最終的に作成されることです。ORM では、このような問題がなくなるため、これが利点として宣伝されています。

問題は、これらの問題が ORM でなくなるわけではなく、単にプレゼンテーション層に移動するということです。クエリの VO/DTO を作成する代わりに、通常はビューごとに 1 つずつ、カスタム プレゼンテーション オブジェクトを作成します。これはどのように優れているのでしょうか。私の意見では、優れているわけではありません。

これについては、ORM または SQL: もうそこに到達したのでしょうか?。

最近私が選んだ (Java での) 永続化テクノロジは ibatis です。これは SQL のかなり薄いラッパーで、JPA でできることの 90% 以上を実行します (十分に文書化されていませんが、関係の遅延読み込みも実行できます)。ただし、オーバーヘッドははるかに少なくなります (複雑さと実際のコードに関して)。

これは、昨年私が書いていた GWT アプリケーションで発生しました。EclipseLink からサービス実装のプレゼンテーション オブジェクトへの変換が大量に発生しました。ibatis を使用していた場合、ibatis で適切なオブジェクトを作成し、スタックの上下に渡す方がはるかに簡単だったでしょう。純粋主義者の中には、これは Bad™ だと主張する人もいるかもしれません。おそらくそうでしょう (理論上は)。しかし、はっきり言って、こうすれば、コードが簡単になり、スタックが簡単になり、生産性が向上したはずです。

おすすめ記事