レシピサイトのDB設計　中間テーブルの必要性

前提・実現したいこと

初投稿・プログラミングを初めて２ヶ月のものです。

DB設計において、中間テーブルを使うパターンとFormオブジェクトを使うパターンのどちらがプログラミングでは正しいのか、お詳しい方に助言をいただけたらと思います。

レシピサイトを作成しています。

menusテーブル　・・・　レシピの名前、作り方
foodstuffsテーブル　・・・　材料、分量、何人前か

初期段階ではこちらのようなテーブル設計で実装していました。

しかし、一つのForm画面から、二つのテーブルに保存したいので、
Formオブジェクトを使えば良いのでは？と考え、こちらの形に変更いたしました。

CREATE TABLE

usersテーブル

Column	Type	Options
nickname	string	null: false
email	string	null: false, unique: true
encrypted_password	string	null: false

Association

has_many :menus
has_many :comments

menusテーブル

Column	Type	Options
title	string	null: false
recipe	text	null: false
hour_id	integer	null: false
price_id	integer	null: false
user	references	null: false, foreign_key: true

Association

belongs_to :user
has_one :foodstuff
has_many :menu_tags
has_many :tags, through: menu_tags
has_many :comments

commentsテーブル

Column	Type	Options
comment	string
user	references	null: false, foreign_key: true
menu	references	null: false, foreign_key: true

Association

belongs_to :user
belongs_to :menu

foodstuffsテーブル

Column	Type	Options
foodstuff_name	string	null: false
quantity	string	null: false
serving	integer	null: false
menu	references	null: false, foreign_key: true

Association

belongs_to :menu
has_many :menus, through: foodstuff_menus
has_many :foodstuff_menus

foodstuff_menusテーブル

Column	Type	Options
foodstuff	references	null: false, foreign_key: true
menu	references	null: false, foreign_key: true

Association

belongs_to :foodstuff
belongs_to :menu

menu_tag_relationsテーブル

Column	Type	Options
menu	references	null: false, foreign_key: true
tag	references	null: false, foreign_key: true

Association

belongs_to :menu
belongs_to :tag

tagsテーブル

Column	Type	Options
name	string	null: false

Association

has_many :menu_tags
has_many :tags, through: menu_tags

考えたこと・調べたこと

そもそも中間テーブルを使うときは多対多の時とのことですが、menusテーブルに対して、foodstuffs(材料)のパターンは一つしかないので中間テーブルを設けることすらおかしいのではと思いましたが。。
他の質問者の方で、同様にレシピサイトの作成をしている方がいらっしゃいましたが、回答者の方は中間テーブルを推奨していました。
中間テーブルを通過してFormオブジェクトへの保存をする手法も見つかりましたが、まず中間テーブルに必要性があるのかが整理しきれずに止まってしまいました。

根本が間違えていてトンチンカンな質問をしていたら申し訳ございません。

補足情報

Ruby 6.0.0
railsを使用しての実装です。
DBはMySQLを使用しています。

追記

中間テーブルを使わない場合はこちらの実装を考えましたが、ご意見いただきたいです。
他のテーブルは上記と同じもので考えていたので省略させていただきました。

menusテーブル

Column	Type	Options
title	string	null: false
recipe	text	null: false
hour_id	integer	null: false
price_id	integer	null: false
user	references	null: false, foreign_key: true

Association

belongs_to :user
has_one :foodstuff

foodstuffsテーブル

Column	Type	Options
foodstuff_name	string	null: false
quantity	string	null: false
serving	integer	null: false
menu	references	null: false, foreign_key: true

Association

belongs_to :menu

Orlofsky

2021/02/08 13:45

ここの掲示板では Markdown の使い方を覚えてください。 URLは https://teratail.com/help/question-tips#questionTips3-7 の [リンク] で [リンク先の説明](http...) に修正してください。

Orlofsky

2021/02/08 13:47

データベースやそのバージョンによって方言が大きいですから、どのデータベースを使うのかを質問のタグで示したり、質問にバージョンも明記した方が適切なコメントが付き易いです。

Orlofsky

2021/02/08 13:50

質問に以下の内容を追記しては？テーブル定義はCREATE TABLEで、テーブル中のデータはINSERTで、現行の考えられるSELECT文、その結果、希望する結果を https://teratail.com/help/question-tips#questionTips3-7 の [コード] で提示しては？

yumi_1003

2021/02/08 14:14

修正依頼ありがとうございます！質問以前の問題があったこと失礼いたしました。希望する結果は、コードではなく中間テーブルを使用するか、Formオブジェクトを使用するかを考えているので、すみませんがどのように記述すれば良いか分かりませんでした。。

Orlofsky

2021/02/08 14:23

中間テーブルを使わないでどんなSELECT文になるかを提示できると良かったのですが。

yumi_1003

2021/02/08 14:35

考えが浅はかでした。ご指摘ありがとうございます！追記にて中間テーブルの無いものを考えました。もしよろしかったらまたご指摘等いただけたら嬉しいです...!

hentaiman

2021/02/08 14:56 編集

rubyが分からないので質問がちょっと見難いので軽いアドバイスですが、まずは中間テーブルを使わない形で作ってみれば良いです。そして実際の利用を想定していそれなりにレシピデータを登録してみましょう。その時に、同じデータの保存し過ぎじゃん！みたいな感想を持ったなら中間テーブルを作れば良いし、特に気にならないなら持たなくて良いです。不特定多数が使うシステムなら冗長なデータを避けるに越したことは無いし、他にも都合が良い事が多いですが、自分専用のレシピ公開だったら冗長なデータの持ち方をしたところで大した量のデータでは無いので気にする事は無いかもしれません。中間テーブルを作らない事で機能の実装に不都合があれば中間テーブルを作るという考え方でも。

yumi_1003

2021/02/08 23:25

貴重なご意見ありがとうございます！

行動規範の内容に同意します

回答2件

ベストアンサー

中間テーブルを使うかどうかと Form オブジェクトを使うかどうかは別問題です。
これは分けて考えるようにしてください。

基本的に、DB 設計は Web アプリケーションの実装に依存することはありません。
どんなデータをどういう風に扱うかによって決めることになります。
実際は Web アプリケーションが扱いやすいように DB 設計を寄せることは普通に行われるので依存しないってことはないんですが、原則的にそうだと思ってください。

で、ここで問題になるのはメニューと材料のデータとその関係性です。
これはやろうとしていることによるのでこれが正解とは一概に言えないのですが、私だったらこんな風にします。

foodstuffs テーブルは food_stuffs テーブルに名前を変える
中間テーブルは使用する（ menu_food_stuffs かな？）
food_stuffs の quantity（分量）は中間テーブル側に保持する。
food_stuffs の serving（何人前か）は menu テーブルに移す（何人前かって材料に持つ意味ないのでは。。）

こうする理由は、menu -> food_stuff だけではなく food_stuffs　-> menu でデータを辿るユースケースを考えると分かりやすいかもしれません。材料名でメニューを検索したいときに、その材料名をプルダウンメニューにしたいってとき、どっちが向いているかなと考えてみると。。
また、材料名を毎回入力させてしまうと、例えば人参、ニンジン、にんじんなどの表記揺れや入力ミスが起こりやすくなります。
材料名は food_stuff で管理されていて、基本的に登録されているものから選ぶ（ない場合に限り新規追加）の仕組みにしておいた方が効率が良くなります。
例えばその後英語表記に対応させたい場合、food_stuff に english_name カラムを追加してそれぞれの材料に対応する英語、例えば carrot を登録するってやれば済みます。レコード一個だけ。
中間テーブルを使わない場合、にんじんが材料として使われている分だけレコードの修正が必要になったりします。

この材料テーブルは基本的に tag テーブルと同じ性格を持っています。
集約できるデータは集約させる（正規化と言います）ようにしておかないと後々の機能追加に追従する柔軟性が失われたり、RDBMS が本来もつ性能を発揮できなかったりします。

この辺りは慣れもあり、非効率な設計にどんな問題があるのか。字面で解説されてもよく分からないかもしれません。
中間テーブルを使わない設計でも機能的には動かせると思うので、とりあえずそれでやってみるのもいいと思いますよ。
実運用していると問題に気づきやすいんですけどね。

投稿2021/02/08 19:57