ORMはツリーのようなDB構造にとって悪いツールですか？

この質問は意見に基づくものとして締めくくられるかもしれませんが、今必要なのは議論によって裏付けられたいくつかの意見です。

PostgresとEcto（Elixir）を永続化レイヤーとして使用してアプリケーションを構築しています。それ自体を参照するエンティティがあるため、それを使用してツリーのような構造を構築できます。Ectoでこれをやろうとすればするほど、いらいらします。

ORMは、多くの関連付けを持つ複雑なDB構造を作成するための単なる悪いツールですか？ORMがリレーショナルデータに適用しようとするオブジェクト指向の方法は、ここでは悪いアプローチのようです。オブジェクトは分離されています。それらが他のオブジェクトと相互作用する場合、それらは（想定されている）メッセージを送信します。彼らの内面の詳細は隠されたままである必要があります。リレーショナルデータは、開いた透明なグラフを形成します。これら二つの世界は私と完全に両立しないようです。

しかし、ORMは非常に一般的で人気があります。Webアプリケーションの大部分はORMでうまく機能する分離されたエンティティで動作しますか、それはなぜですか？ORMフレームワークを使用して平均的に複雑なERDモデルを実装する場合は、簡潔なコードまたはパフォーマンスを犠牲にする必要があるように思われます。

結局のところ、ORMは、SQLを生成してデータをオブジェクトにマップする単なる抽象概念です。いくつかの「ボイラープレート」コードを保存（tm）します。

したがって、ORM全体として、定義上必ずしも不利な点はありません。問題は、ORMを全体として使用しないことです。特定のORMを選択して使用する必要があります。

個々のORMは、特定のことをうまく実行できない場合があります。ストアドプロシージャ、動的SQL、計算フィールド、複雑な結合などが問題になる可能性があります。

より微妙な問題は、ORMがこれらすべてのシナリオを一般的な方法で処理しようとすると、大きくなり、使用が複雑になることです。

大規模または複雑なアプリケーションがある場合、ある時点で、選択したORMで問題が発生する可能性があります。そのため、事前にこれを計画し、ORMをリポジトリの背後に隠すようにすることは理にかなっています。そうすれば、別の方法で自由に交換したり、必要に応じて手動でコード化されたSQLに戻ったりできます。

ORMは、多くの関連付けを持つ複雑なDB構造を作成するための単なる悪いツールですか？

いいえ。例として、Ruby on Railsは関連付けを処理するActiveRecordを使用します。ここの例では、https : //stackoverflow.com/questions/5109893/rails-how-do-self-referential-has-many-models-work、ツリーのような構造は2行のコードで実現されています。

そのため、独自のSQLクエリをロールするよりも簡単だと主張します。

Webアプリケーションの大部分はORMでうまく機能する分離されたエンティティで動作しますか、それはなぜですか？

おそらくそうではありませんが、それは当て推量です。ORMは、繁栄しているエコシステムに存在し、使用されていることを示唆しています。私は、20を超える関連モデルを持つシステムにORMを使用してきましたが、問題はありませんでした。メッセージパッシングのみでオブジェクトを分離することを強制したことはありません。

要約として、「複雑な」ERDモデルを作成している場合、それらを簡単にするツールはありません。それらを機能させるツールのみ。

ここで少なくとも1つの他の回答で述べられているように、すべてのORMは同じではありません。一部のORMは、データベースの構造化方法について非常に重要な想定を行っています。ツールは、このモデルの外への移動をある程度サポートする必要がありますが、そのモデルの外に移動するほど、ORMの価値は低くなります。より支配的なORMツールを使用している場合、暗黙の仮定に基づいてデータベースを設計すると、はるかに優れたエクスペリエンスが得られます。

ORMがなぜ多くの開発者やアーキテクトに不可欠であると見なされているのか、私は本当に理解していません。これは、私が使用するグリーンフィールドデータベースがほとんどないためであり、ORMマッピングを実行するために必要な時間と労力は、SQLを作成するよりもはるかに多くの作業でした。マッピングが単純だった（SQLもそうだった）か、それとも複雑だったので、SQL（または類似の何か）が必要でした。私の経験では、ORMに含まれるトランザクションの「サポート」は、ヘルプよりもバグや問題の発生源でした。

マイレージはさまざまかもしれませんが、データベースの永続化をデータのシリアル化の特別なケースとして考える方がよいと私は信じるようになりました。オブジェクトをネットワーク経由で「送信」できると信じても意味がないと思うのと同じように、データベースにオブジェクトを書き込むことを考えるのはあまり意味がありません。異なるニーズに対して同じデータの複数のオブジェクト表現を持つことは完全に有効だとさえ思います。オブジェクトをテーブルにマッピングしたり、その逆を行ったりすることは、問題の解決策とは対照的に、それ自体の終わりになりました。これらのツールを使用するほとんどの人が、それを実行したい明確な理由があるとは思いません。デフォルトになりました。