No`orm の作成者は、3 つのテーブルの結合を 3 つのより高速なクエリに分解できることを示しています: http://www.notorm.com/#performance。
INステートメントにIDを入れることで、結合を避けて複数のクエリを使用することは可能だと思いますか?
そのライブラリ (NoORM) は、上記の理由で結合をサポートしていません。結合の使用をあきらめて、そのライブラリだけを使用できると思いますか? 結合を簡単に回避できるのは奇妙に思えます。
No`orm の作成者は、3 つのテーブルの結合を 3 つのより高速なクエリに分解できることを示しています: http://www.notorm.com/#performance。
INステートメントにIDを入れることで、結合を避けて複数のクエリを使用することは可能だと思いますか?
そのライブラリ (NoORM) は、上記の理由で結合をサポートしていません。結合の使用をあきらめて、そのライブラリだけを使用できると思いますか? 結合を簡単に回避できるのは奇妙に思えます。
比較的小規模なアプリケーションの場合、これは実現可能です。しかし、多くの引数を渡す可能性がある状況 (多くの行で一致する結合条件に相当) では、これは失敗します。私が考えることができる理由の最良の例は、たとえば、(これが最新バージョンに当てはまるかどうかはわかりません) Informix の制限です。ここでは、準備されたステートメントでは 20 を超える (正確ではありません) 引数が許可されませんでした。渡されます。
個々のクエリで結合を使用する理由の 1 つは、データベースのオプティマイザーが、既存のデータに基づいて、関連するテーブルの最適な計画を考え出すことができるようにすることです。結合されたクエリを個々のクエリに分割すると、実行計画が事実上ハードコーディングされます。とりわけ、これは、コードを記述するときにクエリの選択性について考えることに時間を費やすこと、および選択性がアプリケーションの存続期間中同じままであることを前提としています。私の意見では、これらはかなり大きな仮定です。
また、データベースをただの受け皿以上のものとして使用している場合は、個々のクエリに簡単に分割できないクエリがあることに気付くでしょう (たとえば、集計関数を使用するときはいつでも)。