記事とタグのような多対多を設計するとき、正しいのはどれですか。
記事とタグなら article_tag のような中間テーブルを置いて繋ぎます。Eloquent の定義だけでなくDB側にも外部キー制約を張り、アプリの検査に依存しない状態にします。
面接官が見ているのはDB設計をEloquent任せにしていないか。
よくある答えと、面談でどう見られるか
- 中間テーブルを作って belongsToMany で繋ぎ、DB 側にも外部キー制約を張る
その通りです。アプリ側のチェックはバグやバッチですり抜けるので、最後の砦は DB 側に置きます。 - 記事テーブルにタグを カンマ区切りの文字列で持つ
検索も集計もできなくなり、正規化の観点からも避けます。 - タグの数だけ記事テーブルにカラムを追加する
タグが増えるたびにスキーマ変更が必要になります。 - hasMany を両側のモデルに書く
多対多では belongsToMany を両側に書きます。hasMany は1対多です。
面接官は何を見ているか
- 具体的なリレーション種別を挙げた
- 中間テーブルの存在を説明できた
- 外部キー制約に触れた
模範解答
多対多は中間テーブルを作って belongsToMany で繋ぎます。たとえば記事とタグなら article_tag テーブルを置きます。Eloquent 側の定義だけでなく、DBにも外部キー制約を張ります。アプリ側の整合性チェックはバグやバッチ処理ですり抜けるので、最後の砦はDB側に置くべきだと考えています。
ここからどう深掘りされるか
この問いに答えられた場合、面談は次の質問に進みます。
観点をすべて押さえられた場合
ポリモーフィックリレーションの代償は何ですか。一部しか触れられなかった場合
中間テーブルに追加の情報（並び順や登録日時など）を持たせたい場合、どうしますか。