Railsでモデルを4段階joinする方法で、もう一度理解するjoinsとmerge

こんにちは、インターネットコンテンツ兼新米エンジニアのTerryです。

日曜日にQiitaを投稿しても伸びないことは知っている。
でもそこは何があったか察してほしい、すまない。

さて本日は、**Railsでモデルを４段階joinする方法**についてお伝えします。
その過程でjoinsについて分解して解説して、joinsへの理解を深めます。

最初に断っておくと、この書き方は僕の尊敬する先輩エンジニアに教えていただいたもので、僕の備忘と理解を深めるため無断で掲載しようと思った次第です<del>怒られたら削除します</del>。

２段階（孫）とか３段階（ひ孫）は結構あるんですが、4段階（玄孫[やしゃご]）はあまりノウハウが転がっていなかったので、こんなやりかたもあるよ、って感じで知っておくとどこかで使えるかもしれません。

4段階、玄孫ですよ。
どれだけ遠いかって言うと、大久保利通の玄孫が麻生太郎です。幕末か。

![okubo_kakeizu-e1514640958101.jpg](https://qiita-image-store.s3.amazonaws.com/0/110571/e86824df-bc5f-eabd-15e4-e95c27502ef1.jpeg)
（画像は<a href="https://under-the-veil.jp/11849.html#st-toc-h-2">UNDER THE VAILさん</a>より引用）

いやいやお前、４段階もjoinするデータベースの設計がおかしい、見直せという、至極真っ当なご意見があるかと思いますが、とはいえ生きていればそういうこともあるよね。こんな大人になっちゃいけません。

さぁ、皆さんのご理解を頂いたところで、早速進めていきましょう。

## テーブル構造
今回想定するテーブルはこんな感じです。

```rb

class Parent < ApplicationRecord
    belongs_to :children
end

class Child < ApplicationRecord
    has_many :parents
    has_many :grand_sons
    has_many :great_grandsons, through: :grandsons
end

class GrandSon < ApplicationRecord
    # 中間テーブルです
    belongs_to :child
    belongs_to :great_grand_son
end

class GreatGrandSon < ApplicationRecord
    belongs_to :great_great_grandson
    has_many :grand_sons
end

class GreatGreatGrandSon < ApplicationRecord
    has_many :great_grand_sons
end

```

ちょっとアソシエーションが複雑ですが、実際の実装に近いイメージを想定しているためご容赦を。
実際、キレーにhas_manyやbelongs_toが通ってる例だと、実践で使えない気もします。

ちなみに、grand sonは孫、great grand sonはひ孫、great great grand sonは玄孫という意味らしい。
greatが増えると、どんどん世代が深くなるイメージです。英語って表現力が貧弱やな。

ちなみにちなみに、図にするとこんな感じ。

<img width="795" alt="スクリーンショット 2018-06-03 17.47.56.png" src="https://qiita-image-store.s3.amazonaws.com/0/110571/16866c0d-8b7c-fe4d-f5c2-83ef39ec6958.png">

実践のアソシエーションにモデル名を無理やり乗っけたから、関係性がよくわからんことになっている。やばい。
しかし、他にわかりやすいのも思いつかなかったため、コレで行く。オレは正しい。

## 何がしたいか
今回は、GreatGreatGrandSonのidから、じっちゃんの名にかけて、それに紐づくParentを引きずり出してやりたい。

ちなみに、SQLで書くとこんなかんじ。
INNER　JOIN大明神。

```sql

SELECT 
  *
FROM 
  parents
  INNER JOIN
    children
  ON
    children.id = parent.child_id    
  INNER JOIN
    grand_sons
  ON
    grand_sons.id = children.grand_son_id 
  INNER JOIN
    great_grand_sons
  ON
    great_grand_sons.id = grand_sons.great_grand_son_id
  INNER JOIN
    great_great_grand_sons
  ON
    great_great_grand_sons.id = great_grand_sons.great_great_grand_son_id
  AND
    great_great_grand_sons.id = {{funfun}}
```

整理するために、もう一度図で確認しましょう。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/110571/093268b4-7cec-65dc-c3bf-82b2acce0d88.png)

クエリだとINNER JOIN連発するだけで、特に難しいことはないです。
しかし、Railsでは結構面倒な書き方をしないといけないので、次で解説します。

## Railsでの書き方
さて、先ほどのクエリをRailsでやってみましょう。
結論から言うと、こんな書き方です。
（無駄に長いので、折り返します）

```rb


Parent.joins(
  child: [
    great_grand_sons: :great_great_grand_son
  ]
).merge(GreatGreatGrandSon.where(id: funfun))
```

他にも書き方はいろいろありますが、とりあえず今回はこれ。

ちょっとやる気がなくなってきた。つらい。
しかし、頑張ってひとつずつ分解して説明します。

### joinsメソッド
最初のjoinsメソッドですが、これは、**モデル間の結合**を行います。
形としては、こんな感じ。

```rb

Model名.joins(繋げたいtable)
```

joins - リファレンス - - Railsドキュメント
（http://railsdoc.com/references/joins）

つまり、joinsメソッドは、**SQLでいうところINNER JOINを行ってくれる**わけですね。
INNER JOINと少し違う点は、「**条件に何も入れなければ、勝手にアソシエーションを使って紐付けてくれる（id同士を指定しなくても良い）**」というところです。

上の例で発行されるクエリがこちら。

```sql

SELECT 
  models.* 
FROM 
  modes 
  INNER JOIN
    tables
  ON
    models.table_id = tables.id
```

ちなみに、他にも似たような動きをするメソッドにincludesがあります。
**N+1問題に気を遣う場合**はincludes使おうね。

似ているようで全然違う!?Activerecordにおけるincludesとjoinsの振る舞いまとめ
（https://qiita.com/south37/items/b2c81932756d2cd84d7d）

ここまでは普通のjoinsなんですが、ちょっとうざいのが中身の条件節です。

Railsで書いたコードをもう一度見てみましょう。
joins下は、こうなっています。

```rb

.joins(child: [great_grand_sons: :great_great_grand_son])
```

気になる点が２つあると思います。

１つ目は、前半の「child: ...」となっている部分（:childじゃないの？）
２つ目は、[great_grand_sons: :great_great_grand_son]のところ。

さて、これら２つのポイントは、実は**１つの表現**に集約されています。
答えは「**ネスト**」です。

Model.joins(hoge: :fuga)とした場合、fugaとhogeがINNER JOINされ、その結果がmodelにINNER JOINされます。fugaがhogeにネストされている状態です。
SQLで書くとこうなります。

```sql

SELECT 
  models.* 
FROM 
  models 
  INNER JOIN
    hoges
  ON
    models.hoge_id = hoges.id
  INNER JOIN
    fugaes
  ON
    fugas.hoge_id = fugas.id
```

この説明でピンときた人もいるかも知れませんが、２つ目の[great_grand_sons: :great_great_grand_son]の部分も同じくネストです。

つまり、**２重にネストしている**だけの話なんですね。
もう一度、joins下のコードを見てみます。

```rb

.joins(child: [great_grand_sons: :great_great_grand_son])
```

考え方としては、**後ろから解決する**とわかりやすいです。

まずgreat_grand_sons: :great_great_grand_sonをINNER JOINします。
その結果を、今度はchildとINNER JOINするのです。

おいgrand_sonどこいった、って感じですが、grand_sonは中間テーブルです。
ちゃんとアソシエーション張っていれば、これで問題なく通ります。<del>Railsって便利。</del>

grand_sonが中間テーブルでないパターンを想定する場合は、childではなくgrand_sonにすれば良いです。

さて、これでやりたいことの８割位は説明できました。

```sql

SELECT 
  *
FROM 
  parents
  INNER JOIN
    children
  ON
    children.id = parent.child_id    
  INNER JOIN
    grand_sons
  ON
    grand_sons.id = children.grand_son_id 
  INNER JOIN
    great_grand_sons
  ON
    great_grand_sons.id = grand_sons.great_grand_son_id
  INNER JOIN
    great_great_grand_sons
  ON
    great_great_grand_sons.id = great_grand_sons.great_great_grand_son_id
  /* ここまで */
  AND
    great_great_grand_sons.id = {{funfun}}
```
それでは、最後にmergeメソッドに入りましょう。

### mergeメソッド
mergeメソッドといっても、２つあります。
ひとつはRuby自体のメソッドで、ハッシュの結合に利用するものです（今回は説明を割愛します）。

merge, merge! (Hash) - Rubyリファレンス - AmiWiki
（https://ref.xaio.jp/ruby/classes/hash/merge）

もうひとつは、ActiveRecordのmergeメソッドです。
今回は言うまでもなくこちらですね。
（mergeってドキュメントないから困る）

mergeは、**複数の条件を併合（＝マージ）する**メソッドです。

ざっくり言うと、**直前に行った条件に対して、さらに絞り込みを行いたい時**に使います。
SQLでいうと、**最後に書くWHERE句**的な感じですかね。

ここで、もう一度コードを見ましょう。

```rb

Parent.joins(
  child: [
    great_grand_sons: :great_great_grand_son
  ]
).merge(GreatGreatGrandSon.where(id: funfun))
```

今回は、先ほどJOINした結果のParentにさらに絞り込みを掛けるイメージです。
絞り込む条件は、「idがfunfunであるGreatGreatGrandSon」ということですね。

mergeの中の条件は簡単なので説明はいらないと思います。

ちなみに、mergeの一般的な使い方はコレではなく、**モデルのscopeを利用するパターン**が多いと思います。
scopeについては、こちら。

Ruby On Railsのscopeメソッドで検索を効率化する
（https://programming-beginner-zeroichi.jp/articles/62）

ざっくり言うと、**「よく使う絞り込みを、あらかじめモデル内に設定しておく」**ということですね。

今回はmergeのこの機能を使わず、単に条件を追加する用途で使っています。
モデルによってscopeをうまく設定して使ってあげることで、controllerの記述をシンプルにして、fat_controller化することを防げますので、効率的に使いましょう。

## 終わりです！

以上、４段階もjoinする話からjoinsとmergeについて説明してみました！

余裕があれば、クエリの実行計画や結果を吐き出して、どのメソッドや書き方が早いのか、４段階JOINで処理が遅くならないかなど検証したいと思います。