効率の観点から、以下のベストプラクティスは何だろうと思っています。
いくつかのフィールドを持つ「blogPosts」というテーブルがあります。列 blogPost_Id を含む「comments」というテーブルもあります。
1 つのブログ投稿に多数のコメントが含まれる場合があります。
すべての投稿とすべてのサブコメントに関するすべての情報を取得したいのですが、これを次のような 1 つの SQL コマンドに含めることをお勧めします。
SELECT * FROM blogPosts LEFT JOIN comments ON blogPosts.id = comments.blogPost_id
それともしたほうがいいですかSELECT * from blogPosts
そして、SELECT * from comments WHERE blogPost_id=postId投稿ごとに別のことをしますか？
投稿およびコメント フィールドに基づいて SQL にフィルターを追加することを付け加えておきます。
データベースへの接続にはコストがかかります。やらないほうがいい。
別の言い方をすれば、どちらが速いですか? 1,000 個の箱を降ろすために 1,000 回の移動を行うか、1,000 個の箱を降ろすために 1 回の移動を行うか?
質問のような単純なクエリの場合、データベースに結合させます。これについては疑問の余地はありません。
より複雑なクエリについても議論があるかもしれませんが、データベースは大量のデータを処理するように設計されています。アプリケーションでデータベースの作業を複製しようとすることは表現されていません。
とはいえ、データベース オプティマイザ/エンジンが混乱する場合もあります。このような場合、一時テーブルを作成するか、アプリケーションで作業を行う必要がある場合があります。これは良いことではなく、現実です。
アプリケーション層が最も得意とすることは、アプリケーション層に任せましょう。データベースが最も得意とすることはデータベースに任せましょう。これにはデータの処理も含まれます。
原則として、データベースへのラウンド トリップは少ない方がよいため、通常は 1 つの巨大なクエリが優先されます。
ただし、それはルールではありません。インデックスを適切に設定しないと、実際にはクエリが大幅に遅くなる可能性があります。もう 1 つ注意すべき点は、コードの複雑さと保守性です。私はかつて、約 17 個のテーブルを結合する非常に複雑なクエリを作成しました。デバッグと変更は悪夢でした。
ベンチマークは、パフォーマンスを測定するための唯一のツールであるため、非常に重要です。実際に、クエリを分割するとパフォーマンスが向上することがあります。
私が見る限り、あなたのクエリは、1 つのクエリで結合を実行してそれを回避するのに十分単純です。