orm - O/R マッピングの価値はありますか?

Question

ORM で提供されるクエリ言語 (QL) の表現力は非常に強力です。残念なことに、一連の複雑なクエリがあり、不可解なスキーマまたはデータの問題が発生すると、必要な DBA の助けを借りるのは非常に困難です。ここにいるのは、データベースを進化させているチームの一員ですが、アプリケーションの QL を読み取ることはできず、ましてや変更を提案することもできません。私は通常、生成された SQL をログから取得します。しかし、彼らが変更を推奨した場合、それは元の QL とどのように関係するのでしょうか? プロセスは往復ではありません。

そのため、ORM の価値を 10 年にわたって宣伝してきた今、SQL を手動で作成する必要があるかどうか疑問に思っています。そして、私が本当にフレームワークに求めているのは、データ マーシャリングを可能な限り自動化することだけかもしれません。

質問: 組織内で往復の問題に対処する方法を見つけましたか? 拡張性が高く、保守が容易な SQL マーシャリング フレームワークはありますか?

(はい、純粋な SQL が私をデータベース ベンダーに結びつける可能性があることは知っています。しかし、標準に準拠した SQL を作成することは可能です。)

Answer 1

あなたが求めているのは、他の手段の使用を妨げることなく、ORM の利点を最大化するソリューションだと思います。私たちのアプリケーションであなたがしたのとほとんど同じ問題があります。非常に重いクエリと大規模なデータ モデル。データ モデルのサイズを考えると、ORM は大部分のアプリケーションにとって非常に貴重です。これにより、手作業で SQL スクリプトを維持するという多大な労力を費やすことなく、データ モデルを拡張することができます。さらに、これについても触れましたが、私たちは 4 つのデータベース ベンダーをサポートしているため、抽象化は優れています。

ただし、クエリを手動で調整しなければならない場合があり、柔軟な ORM ソリューションを選択したため、それも可能です。あなたが言うように、それは必要なときに私たちの邪魔にならず、単にオブジェクトをマーシャリングしてくれます。

つまり、要するに (はい、短い) はい、ORM は価値がありますが、問題に対するすべてのソリューションと同様に、万能薬ではありません。

Answer 2

一般に、ORM は開発者の生産性を大幅に向上させるので、その価値よりも大きな問題にならない限り、私は ORM を使用します。テーブルの大部分が十分に大きく、多くの問題が発生している場合は、ORM を捨てることを検討してください。ORM が一般的に悪い考えだとは絶対に言いません。ほとんどのデータベースは十分に小さく、ほとんどのクエリは十分に単純なので、うまく機能します。

ストアド プロシージャまたは手書きの SQL を、パフォーマンスの低いクエリに対してのみ使用することで、この問題を克服しました。DBA はストアド プロシージャを好みます。ユーザーに知らせずに変更できるからです。ほとんどの (すべてではないにしても) ORM では、手書きの SQL またはストアド プロシージャを混在させることができます。

Answer 3

今日の O/R フレームワークは、おなじみだと思いますが、一部のクエリを手動で定義するオプションをサポートしています ((N)Hibernate ではサポートされています)。これはスキーマの複雑な部分に使用でき、単純な部分にはフレームワークによって提供される ORM を使用します。

他にチェックアウトする必要があるのは、iBatis フレームワーク ( http://ibatis.apache.org/ ) です。私はそれを使用していませんが、SQL に近いことを読んだことがあります。データベースと SQL に精通している人は、ORM の完全に異なる概念よりも SQL の方が近いため、hibernate のような本格的な ORM フレームワークよりも SQL を好みます。