ORM は柔軟性がなく、「漏れやすい抽象化」であるとバッシングしている人をよく耳にしますが、なぜORM が問題になるのかについてはあまり聞いていません。適切に使用した場合、ORM の正確な欠点は何ですか? 私は PHP orm に取り組んでおり、遅延読み込みやサブクエリの欠如など、他の多くの ORM が失敗する問題を解決したいので、これを求めています。
具体的にお答えください。コードを表示するか、ORM が苦労するデータベース スキーマを説明してください。言語や ORM は関係ありません。
ORM は柔軟性がなく、「漏れやすい抽象化」であるとバッシングしている人をよく耳にしますが、なぜORM が問題になるのかについてはあまり聞いていません。適切に使用した場合、ORM の正確な欠点は何ですか? 私は PHP orm に取り組んでおり、遅延読み込みやサブクエリの欠如など、他の多くの ORM が失敗する問題を解決したいので、これを求めています。
具体的にお答えください。コードを表示するか、ORM が苦労するデータベース スキーマを説明してください。言語や ORM は関係ありません。
私が使用したすべての ORM で気付いた大きな問題の 1 つは、最初にオブジェクトを取得せずにいくつかのフィールドのみを更新することです。
たとえば、次のフィールドを持つ Project オブジェクトがデータベースにマップされているとします: Id、name、description、owning_user。たとえば、ajax を使用して、説明フィールドを更新したいとします。ほとんどの ORM では、ID と説明の値しかないときにデータベース テーブルを更新する唯一の方法は、データベースからプロジェクト オブジェクトを取得し、説明を設定してから、オブジェクトをデータベースに送り返すことです (したがって、2 つのデータベース操作が必要です)。 1回の簡単な更新のためだけに)またはストアドプロシージャを介して更新します(これは私が現在使用している方法です)。
オブジェクトとデータベース レコードは、それほど似ているわけではありません。物を保管できるタイプのスロットがありますが、それだけです。データベースには、プログラミング言語とはまったく異なる ID の概念があります。複合オブジェクトをうまく処理できないため、代わりに追加のテーブルと外部キーを使用する必要があります。ほとんどの場合、型継承の概念がありません。また、オブジェクトのネットワークをナビゲートする自然な方法 (1 つのオブジェクト内のいくつかのポインターをたどり、別のオブジェクトを取得し、再度逆参照する) は、データベースの世界にマップされると効率が大幅に低下します。あなたが気にしなかったデータの。
言い換えれば、そもそも抽象化をうまく行うことはできません。悪いのは ORM ツールではなく、それらが実装するメタファーです。完全な同形ではなく、表面的な類似性にすぎないため、タスク自体はあまり良い抽象化ではありません。(とはいえ、データベースを詳しく理解する必要がある場合よりもはるかに便利です。ORM ツールに対する軽蔑は、ほとんどの場合、単なるプログラマーを見下す DBA から生じます。)
ORM は効率の悪いコードを書くこともできます。データベースのパフォーマンスはほとんどのシステムにとって重要であるため、人間がコードを書いていれば回避できた問題が発生する可能性があります (ただし、問題の人間がデータベースのパフォーマンス チューニングを理解していなければ、問題は改善されなかった可能性があります)。これは、クエリが複雑になる場合に特に当てはまります。
私の最大の問題は、詳細を抽象化することで、ジュニアプログラマーが、エッジケースや ORM が本当に悪いコードを書く場所を処理できるようにするために必要なクエリの書き方をあまり理解していないことだと思います。基本を理解する必要がなかったときに、高度なことを学ぶのは本当に難しいです。結合、グループ化、高度なクエリを理解している人が ORM を手にするのは良いことです。ブール代数と結合、およびその他の基本的な SQL の概念を理解していない人の手に渡ると、データベースとクエリの設計が非常に貧弱になるという非常に悪いことです。
リレーショナル データベースはオブジェクトではないため、そのように扱うべきではありません。ワシをシルクの財布にしようとする試みは、一般的に成功しません。悪い財布と死んだワシを持っているよりも、ワシが得意なこととその理由を学び、ワシを飛ばす方がはるかに良い.
ORM は非常に複雑な問題を解決しようとしています。明確な解決策がないエッジ ケースと主要な設計上のトレードオフが数多くあります。状況 A の ORM 設計を最適化すると、本質的に状況 B の解決が困難になります。
遅延読み込みとサブクエリを「十分」な方法で処理する ORM がありますが、「十分」から「優れた」状態に移行することはほとんど不可能です。
ORM を設計するときは、ORM で処理することが予想されるすべての厄介なデータベース設計を適切に処理する必要があります。どの状況を扱いにくくするかについて、明示的にトレードオフを行う必要があります。
私は、ORM が柔軟性に欠けているとか、平均的な複雑な抽象化よりも漏れやすいとは考えていません。そうは言っても、特定のORMはそれらの点で他のものよりも優れています.
車輪の再発明を頑張ってください。