【Rails入門説明書】joinsについて解説

はじめに

実運用するRailsアプリケーションに、テーブルが1つだけということはあまりないでしょう。

ほとんどの場合、いくつかのテーブルを持って、それらが関連したデータベース構成になっているでしょう。

そういった構造のデータベースから必要なデータを取得する場合に使われるメソッドの1つが、joinsメソッドです。

joinsメソッドを利用することで、関連するテーブルからデータを取得する（ように見える）ので、その後の処理がすっきりと分かりやすくなります。

今回は、そんなjoinsメソッドについて、詳しく解説いたします。

joinsの動き

最初に、joinsメソッドがどのような動きでデータベースからデータを取得してくるのかを説明しましょう。

“未経験”でもたった1ヶ月で営業からエンジニアとして転職！『WebCamp』受講者インタビュー

では、joinsメソッドの動きを説明しましょう。

まず、改めて「localhost:3000/items」を読み込んでください。そして、今度はブラウザの画面ではなく、サーバーを実行しているコマンドプロンプトに目を移します。

そこには、以下のようなログが表示されていることでしょう。

[bash]
Processing by ItemsController#index as HTML
Rendering items/index.html.erb within layouts/application
Item Load (0.0ms) SELECT “items”.* FROM “items”
└app/views/items/index.html.erb:17
Seller Load (0.0ms) SELECT “sellers”.* FROM “sellers” WHERE “sellers”.”id” = ? LIMIT ? [[“id”, 3], [“LIMIT”, 1]]
└app/views/items/index.html.erb:20
Seller Load (0.9ms) SELECT “sellers”.* FROM “sellers” WHERE “sellers”.”id” = ? LIMIT ? [[“id”, 2], [“LIMIT”, 1]]
└app/views/items/index.html.erb:20
Seller Load (0.0ms) SELECT “sellers”.* FROM “sellers” WHERE “sellers”.”id” = ? LIMIT ? [[“id”, 4], [“LIMIT”, 1]]
└app/views/items/index.html.erb:20
CACHE Seller Load (0.0ms) SELECT “sellers”.* FROM “sellers” WHERE “sellers”.”id” = ? LIMIT ? [[“id”, 2], [“LIMIT”, 1]]
└app/views/items/index.html.erb:20
Seller Load (1.0ms) SELECT “sellers”.* FROM “sellers” WHERE “sellers”.”id” = ? LIMIT ? [[“id”, 1], [“LIMIT”, 1]]
└app/views/items/index.html.erb:20
Seller Load (0.0ms) SELECT “sellers”.* FROM “sellers” WHERE “sellers”.”id” = ? LIMIT ? [[“id”, 5], [“LIMIT”, 1]]
└app/views/items/index.html.erb:20
CACHE Seller Load (0.0ms) SELECT “sellers”.* FROM “sellers” WHERE “sellers”.”id” = ? LIMIT ? [[“id”, 2], [“LIMIT”, 1]]
└app/views/items/index.html.erb:20
CACHE Seller Load (1.0ms) SELECT “sellers”.* FROM “sellers” WHERE “sellers”.”id” = ? LIMIT ? [[“id”, 5], [“LIMIT”, 1]]
└app/views/items/index.html.erb:20
[/bash]

ここで注目すべきなのは、3行目の「SELECT “items”.* FROM “items”」というSQLです。

これは、itemコントロールのindexメソッドにある以下のプログラムコードが、SQLに変換された結果です。
(app/controllers/items_controller.rb)

:
def index
@items = Item.all
end
:

つまり、allメソッドを利用することで、itemテーブルのすべての要素を抽出する（SELECT）SQLを生成するわけです。

では次に、allメソッドをjoinsメソッドへ変更してみましょう。
(app/controllers/items_controller.rb)

:
def index
# @items = Item.all # コメントアウト
@items = Item.joins(:seller) # 追記
end
:

そして、再度ブラウザで「localhost:3000/items」を読み込み、コマンドプロンプトのログを見てみましょう。（ちなみに、ブラウザ上の表示に変化はありません）

[bash]
Processing by ItemsController#index as HTML
Rendering items/index.html.erb within layouts/application
Item Load (1.0ms) SELECT “items”.* FROM “items” INNER JOIN “sellers” ON “sellers”.”id” = “items”.”seller_id”
└app/views/items/index.html.erb:17
Seller Load (1.0ms) SELECT “sellers”.* FROM “sellers” WHERE “sellers”.”id” = ? LIMIT ? [[“id”, 3], [“LIMIT”, 1]]
└app/views/items/index.html.erb:20
Seller Load (0.0ms) SELECT “sellers”.* FROM “sellers” WHERE “sellers”.”id” = ? LIMIT ? [[“id”, 2], [“LIMIT”, 1]]
└app/views/items/index.html.erb:20
Seller Load (1.0ms) SELECT “sellers”.* FROM “sellers” WHERE “sellers”.”id” = ? LIMIT ? [[“id”, 4], [“LIMIT”, 1]]
└app/views/items/index.html.erb:20
CACHE Seller Load (1.0ms) SELECT “sellers”.* FROM “sellers” WHERE “sellers”.”id” = ? LIMIT ? [[“id”, 2], [“LIMIT”, 1]]
└app/views/items/index.html.erb:20
Seller Load (1.0ms) SELECT “sellers”.* FROM “sellers” WHERE “sellers”.”id” = ? LIMIT ? [[“id”, 1], [“LIMIT”, 1]]
└app/views/items/index.html.erb:20
Seller Load (0.8ms) SELECT “sellers”.* FROM “sellers” WHERE “sellers”.”id” = ? LIMIT ? [[“id”, 5], [“LIMIT”, 1]]
└app/views/items/index.html.erb:20
CACHE Seller Load (0.0ms) SELECT “sellers”.* FROM “sellers” WHERE “sellers”.”id” = ? LIMIT ? [[“id”, 2], [“LIMIT”, 1]]
└app/views/items/index.html.erb:20
CACHE Seller Load (0.0ms) SELECT “sellers”.* FROM “sellers” WHERE “sellers”.”id” = ? LIMIT ? [[“id”, 5], [“LIMIT”, 1]]
└app/views/items/index.html.erb:20
[/bash]

こちらも、3行目のSQLに注目してください。

allメソッドで生成されたSQLより少し複雑になって、以下の処理が追加されています。

「INNER JOIN “sellers” ON “sellers”.”id” = “items”.”seller_id”」

このSQLは、「sellerテーブルのidとitemテーブルのseller_idが等しい、sellerテーブルレコードを内部結合する」という意味です。

つまり、allメソッドとjoinsメソッドでは、表示される結果は同じですが、内部的に以下のような違いがあります。

・allメソッド　：itemテーブルのすべてのレコードを抽出する
・joinsメソッド：itemテーブルに登録されているseller_idと等しいidを持つsellerテーブルのレコードを内部結合した結果を抽出する

「内部結合」というのは、簡単に説明すると「関連する双方のテーブルにデータがあるレコードだけを結合する」ということです。つまり、idが一致するsellerテーブルのデータがitemテーブルにくっついたテーブルを作り出しているということです。

joinsとallの具体的な違い

今のままでは、allメソッドとjoinsメソッドに明確な違いはないように見えます。

しかし、実際には大きな違いがありますので、分かりやすくプログラムコードを修正してみましょう。

絞り込む対象は、「販売者名が”Ohashi”」のレコードです。

まずは、allメソッドの場合の絞り込みを試してみます。
(app/controllers/items_controller.rb)

:
def index
@items = Item.all.where([“sellers.name = ?”, “Ohashi”]) # 変更
# @items = Item.joins(:seller) # コメントアウト
end
:

残念ながら、エラーが出てしまいます。

これは、itemテーブルにsellers.nameなどというカラムがないからです。

最初に説明したとおり、allメソッドは指定のテーブルのレコードをすべて取得するだけです。この段階ではsellerテーブルのデータはありませんので、当然のようにカラムが見つからないわけです。
※ブラウザ上で販売者の名前が表示されていますが、これはビューで販売者名を表示するプログラムコードがあり、そのときに改めてSQLが生成されて、データベースから読み込んでいるのです

そのため、もしallメソッドを使って販売者名で絞り込むのであれば、seller_idを指定して、以下のようにする必要があります。
(app/controllers/items_controller.rb)

:
def index
@items = Item.all.where([“seller_id = ?”, 2]) # “Ohashi”のid
# @items = Item.joins(:seller) # コメントアウト
end
:

前述のとおり、joinsメソッドはテーブルを結合しています。そのため、allメソッドのようにわざわざseller_idを指定する必要がありませんので、さきほどallメソッドでエラーが出たwhereのプログラムコードを使うことができます。
(app/controllers/items_controller.rb)

:
def index
# @items = Item.all.where([“seller_id = ?”, 2]) # “Ohashi”のid コメントアウト
@items = Item.joins(:seller).where([“sellers.name = ?”, “Ohashi”]) # “Ohashi”で絞り込み
end
:

このように、joinsは関連するテーブルのデータを使って絞り込みを行うときに、その真価を発揮するのです。

https://web-camp.io/magazine/archives/12481

joinsの使い方

joinsメソッドの使い方を、構文から整理しておきましょう。

構文

joinsメソッドの構文は、とてもシンプルです。

モデル.joins(テーブル名のシンボル,,,)

joinsメソッドはモデルクラスのメソッドですので、モデルが保持しているテーブルを主にして考えます。つまり、モデルが保持しているテーブルのカラムにあるidと、引数として渡されたテーブルのレコードのidを比較して、一致したものを内部結合するのです。

また、テーブルは複数渡すことも可能です。

例えば、itemテーブルとsellerテーブルの他に、buyerテーブルがあったとして、itemテーブルにsellerとbuyerのidを持っていれば、以下のようにして合計3つのテーブルを内部結合することができます。

Item.joins(:comment, :buyer)

同様に、ネストした結合も可能です。テーブルのネストというのは、AテーブルをBテーブルが参照し、BテーブルをCテーブルが参照するといった、連続して参照しているような関連のことです。

その場合、次のような記載になります。

C.joins(:b => :a)

joinsのメリット・デメリット

前述までの説明で、関連のあるテーブルを扱う場合は、joinsを使った方が良いことが分かりました。

しかし、残念ながら大きなデメリットもありますので、安易に使うのは避けた方が良いときもあります。

ここでは、そんなjoinsメソッドのデメリットを紹介し、そこから改めてメリットを説明しましょう。

デメリット：N+1問題

joinsメソッドのもっとも大きなデメリットが、「N+1問題」です。

先ほどから何度か確認している、joinsメソッド実行時のログを、改めて確認してみましょう。

[bash]
Processing by ItemsController#index as HTML
Rendering items/index.html.erb within layouts/application
Item Load (1.0ms) SELECT “items”.* FROM “items” INNER JOIN “sellers” ON “sellers”.”id” = “items”.”seller_id”
└app/views/items/index.html.erb:17
Seller Load (1.0ms) SELECT “sellers”.* FROM “sellers” WHERE “sellers”.”id” = ? LIMIT ? [[“id”, 3], [“LIMIT”, 1]]
└app/views/items/index.html.erb:20
Seller Load (0.0ms) SELECT “sellers”.* FROM “sellers” WHERE “sellers”.”id” = ? LIMIT ? [[“id”, 2], [“LIMIT”, 1]]
└app/views/items/index.html.erb:20
Seller Load (1.0ms) SELECT “sellers”.* FROM “sellers” WHERE “sellers”.”id” = ? LIMIT ? [[“id”, 4], [“LIMIT”, 1]]
└app/views/items/index.html.erb:20
CACHE Seller Load (1.0ms) SELECT “sellers”.* FROM “sellers” WHERE “sellers”.”id” = ? LIMIT ? [[“id”, 2], [“LIMIT”, 1]]
└app/views/items/index.html.erb:20
Seller Load (1.0ms) SELECT “sellers”.* FROM “sellers” WHERE “sellers”.”id” = ? LIMIT ? [[“id”, 1], [“LIMIT”, 1]]
└app/views/items/index.html.erb:20
Seller Load (0.8ms) SELECT “sellers”.* FROM “sellers” WHERE “sellers”.”id” = ? LIMIT ? [[“id”, 5], [“LIMIT”, 1]]
└app/views/items/index.html.erb:20
CACHE Seller Load (0.0ms) SELECT “sellers”.* FROM “sellers” WHERE “sellers”.”id” = ? LIMIT ? [[“id”, 2], [“LIMIT”, 1]]
└app/views/items/index.html.erb:20
CACHE Seller Load (0.0ms) SELECT “sellers”.* FROM “sellers” WHERE “sellers”.”id” = ? LIMIT ? [[“id”, 5], [“LIMIT”, 1]]
└app/views/items/index.html.erb:20
[/bash]

これは、リストを全件表示したときのログです。

ここで、9つのSQLが生成されているところがポイントです。

これらのSQLを詳しく見てみると、最初のSQLでitemテーブルを取得し、取得したレコードを表示する際に、販売者の名前を取得するためのSQLが生成されてsellerテーブルにアクセスしています。

つまり、リストを表示するのに、テーブルのレコード数+1回のデータベースアクセスが発生しているのです。そのため、テーブルが数百、数千というレコードで構成されている場合、データベースへのアクセスが膨大になり、パフォーマンスに影響が出ます。

これが、「N+1問題」です。

そのため、一覧表示などではjoinsメソッドを使うべきではありません。代わりにincludesメソッドやpreloadメソッドなどを使うようにしましょう。

なお、joinsメソッドによってN+1問題が起きる原因は、joinsメソッドが関連性を保持せず、ただ抽出するだけだからです。ただ抽出した結果を持っているだけですので、表示するためのデータを取得するために、データベースへアクセスする必要があるのです。

メリット：whereと組み合わせて

joinsメソッドのメリットは、「テーブルを結合して絞り込める」点に尽きます。そのため、一般的にjoinsメソッドはwhereメソッドと組み合わせて使うことが多くなります。

そして、前述のデメリットで説明したように、関連性を保持しないため、余計なメモリを消費しません。

この「メモリ消費せずに抽出できる」のは、関連するテーブルの数が多くなればとても効果的に働きます。

多数のテーブルと関連するテーブルを絞り込むだけなのに、すべての関連する値を保持するのは無駄なメモリ消費としか言えません。

メモリが枯渇すると、パフォーマンスに大きな影響を与えます。そのため、「関連しているテーブルの値で抽出した行数を出したい」といった「関連するテーブルの値を使わない処理」の場合は、joinsメソッドとwhereメソッドを組み合わせた方が明らかに効率が良いのです。

https://web-camp.io/magazine/archives/12654

まとめ

Rails のjoinsメソッドについて解説しました。

joinsメソッドは、関連するテーブルを内部結合するため、関連のある複数のテーブルを扱うときに、頻繁に現れます。

しかし、説明したように、joinsメソッドにはN+1問題のリスクがありますので、その使い方には注意が必要です。

N+1問題が発生するのは、関連したテーブルの値へアクセスした場合です。その点を考慮すれば、メモリ消費の少ないjoinsメソッドの使いどころは、「関連するテーブルで絞り込んだレコードの数を表示する」、「メインテーブルのデータだけを表示する」など、いくつも見えてくることでしょう。

こういったメソッドの使い方というのは、知識よりも経験がものを言います。そのため、プログラミングスクールなど対面で説明できる機会を活用して学ぶのは、とても良い方法です。ぜひ、活用していってください。

・allメソッドは、テーブルのデータをすべて取り出す
・joinsメソッドは、関連するテーブルを内部結合したデータを取り出す
・内部結合は、関連しあう2つのテーブルの両方にデータがあるレコードだけを結合する
・外部結合は、関連しあう2つのテーブルのどちらかにデータがあるレコードを結合する
・joinsメソッドで関連するテーブルのデータを扱うと、N+1問題が発生する
・joinsメソッドは関連するテーブルを保持しないため、メモリ消費が少ない
・joinsメソッドはwhereで絞り込んで、関連するテーブルのデータを使わない処理に向いている

【インタビュー】1ヶ月でRubyをゼロから学び、Webエンジニアとして転職！

ブラジルから帰国し技術をつけようとRubyエンジニアを目指してWebCampでRubyを学び、見事Webエンジニアとして転職を果たした田中さんにお話を伺いました。

「Rubyの学習がしたい。基礎をしっかりと理解したい」

「転職のサポートがほしい」

と考えている方はぜひお読み下さい。

https://web-camp.io/magazine/archives/8535