複数のテーブルを作成し，新たにデータを追加する方法

Question

設定

例えば，下記のような2つのテーブルを作成し，1対多のリレーションを設定します。

※tbl_wayはこれ以上データが増えないものとします。
tbl_userのway_idがtbl_wayのidと紐づくようにします。

tbl_user（ユーザーテーブル）

id	name	way_id
1	yamada	1
2	yamada	2
3	yamada	2
3	yamada	3
3	yamada	1

tbl_way（会社への移動手段テーブル）

id	way_name
1	train
2	car
3	walk

質問内容

入力フォームで，氏名（name）と会社への移動手段（way_name）を入力します。
このデータをtbl_userテーブルに保存するためにはどのようにすればよいのでしょうか。
（例：nameにtaro，way_nameにtrainと入力）

検討したこと

way_nameに対応するtbl_way.idを調べ，それをtbl_user.idに代入する方法です。
（上の例で言うと，trainに対応するidが1であることを調べ，
tbl_userのway_idに1を代入する）

ただ，調べてもこのような方法は見つからないので，
おそらく一般的なやり方ではないのだと思いました。
（そもそもできるのかも分かりませんでした）

一般的な方法があれば，ご教示いただけると助かります。
よろしくお願いいたします。

Answer 1

一般的な作り方なら、tbl_wayを元にラジオボタンとかセレクトボックスでも作って、登録時に受け取るPOSTデータがtbl_wayのidになるのようにし、idをvalidationにかけるならtbl_wayに存在するidかどうかを検証します

Comments

[tanukitii]

一瞬で解決しました。そんなやり方があったんですね…。
まだまだ勉強することがありそうです。

ご助言いただき，誠にありがとうございます。

[hentaiman]

めっちゃ理解速いですね。ではついでに、
DB上ではどちらもテーブルも「テーブル」と言いますが、概念としてはtbl_userが「テーブル」でtbl_wayが「マスター」です。
ユーザー情報登録フォームを作る時などは名前や住所などはinput-textでユーザーの任意の入力を受け付けるようにしますが、都道府県や職業や役職のように選択肢が決まっているような項目は予めマスターとしてprefecture_mstやjob_mstというようなテーブルに保管しておき、フォーム出力時はマスターから取得したものをループして出力します。（この場合あとから職業が増えてもDBにinsertすれば済む）
かといって性別のように0 or 1だけで判定出来るようなものはいちいちDBにマスターとして持ちません。精々configファイルに記述して利用すぐ程度です。

一般例として～_mstなどのテーブル名で例えたけど、laravelを使う場合はlaravelに合わせてprefecturesとかにしてしまっていいです。作る側の人が分かってればいいからね

[tanukitii]

確か親と子というやつですよね。tbl_user→子で，tbl_way→親でしたか。
ちなみに現在は，複数に分けたテーブルをleftJoinで結合して，フォームに出力しております。

上記で気になったことが2点ほどございます。
・Javaでconfigと聞けば，何か分かるのですが，laravelではどのファイルに該当するのでしょうか。configフォルダ内に何かファイルを作成するということでしょうか。

・性別のようにconfigファイルに記述するか，マスターとしてデータを持たせるかの判定で，少し分からないことがあります。0 or 1だけで判断できるものなら，configファイルに記述するというのは納得できたのですが，それは2択の場合のみでしょうか。例えば，信号機の色（赤，黄，緑の3種）の情報は，おそらく変わらないと思うので，こちらもconfigファイルに記述しても良いように思いました。何か基準のようなものがあれば，ご教示いただけると幸いです。

よろしくお願いいたします。

[hentaiman]

親と子のリレーションについてはまた別物です。正規化で調べればそれに準ずる情報が出てくると思います。

configという言葉は概念として使いました。
laravelの場合はconfig内にテキトーに作ってconfig関数で呼び出すのが適してると思います。

信号（車）も3択固定値なのでconfigで良いですね。理解されてる通りで、2択だからというよりも今後変更する事が無いから決め打ちしてしまって良いからという理由です。
例で言うと
・職業や役職は増減する可能性があるものだからDBの方が管理しやすく適している
・都道府県は増減しないが件数が多いからDBの方が管理しやすいと思うし、また地域や地方などのデータを持つ可能性もあるのでDBが適している

基準は人それぞれなんですが、自分の場合は面倒くさくない方法を優先します。
慣れとか使いやすさ、見やすさで判断したらいいです。使っててconfigが不適だなと思えばDBに移して作り直しちゃえばいいし。
可変で項目が多い場合でも、DBで定義すると無駄にリレーション張ったテーブルにしなきゃ実現し辛いとか、色々出てくることがあると思うのでその時々で判断です

[tanukitii]

親と子のリレーションの話はまた別でしたか。後ほど調べてみます。
configについても，まだ扱ったことがないので，調べて使ってみようと思います。

もともとの私の質問以外でも多くのことをご教示いただき，誠にありがとうございます。
復習して使えるようにしたいと思います。