回答編集履歴
2
表示崩れを修正
answer
CHANGED
|
@@ -13,7 +13,9 @@
|
|
|
13
13
|
回答へのコメントを受けて追記。
|
|
14
14
|
|
|
15
15
|
すみません、上記の「リレーション」についての回答は、ご推察のとおり
|
|
16
|
+
|
|
16
17
|
> 1会員もしくは複数の会員に紐づくデータを表示させる
|
|
18
|
+
|
|
17
19
|
方法となっております。
|
|
18
20
|
|
|
19
21
|
> 選択肢を表示させる方法
|
|
@@ -38,14 +40,14 @@
|
|
|
38
40
|
|
|
39
41
|
まとめたい理由次第かとは思うのですが、以下、想定される理由別に解決案を書いてみます。
|
|
40
42
|
|
|
41
|
-
想定される理由１）コントローラーに並べると可読性が悪くなるから「ユーザーのマスタ取得系」の処理をまとめたい
|
|
43
|
+
### 想定される理由１）コントローラーに並べると可読性が悪くなるから「ユーザーのマスタ取得系」の処理をまとめたい
|
|
42
44
|
|
|
43
|
-
解決案１－１）
|
|
45
|
+
#### 解決案１－１）
|
|
44
46
|
「サービス」という概念を使い、「ユーザーのマスタ取得」を１つのメソッドにしてしまえば、コントローラーはスッキリします。
|
|
45
47
|
[https://qiita.com/minechan1234/items/2cc7c69875fafb2fdae9](https://qiita.com/minechan1234/items/2cc7c69875fafb2fdae9)
|
|
46
48
|
|
|
47
49
|
|
|
48
|
-
解決案１－２）
|
|
50
|
+
#### 解決案１－２）
|
|
49
51
|
もし、「サービスを導入するのはちょっと敷居が高い」ということであれば、コントローラー内のプライベートメソッドに切り出して、「ユーザー用のマスタ情報を１つの変数にまとめる」だけでも十分見やすくなると思います。
|
|
50
52
|
|
|
51
53
|
```
|
|
@@ -74,6 +76,7 @@
|
|
|
74
76
|
return $user_masters;
|
|
75
77
|
}
|
|
76
78
|
```
|
|
79
|
+
|
|
77
80
|
### 想定される理由２）テーブルにアクセスする回数を減らしたい
|
|
78
81
|
|
|
79
82
|
コードの書き方を工夫したとしても、最終的に「各種テーブルにアクセスしなければならない」という点は変わりません。
|
1
回答へのコメントを受けて、回答内容追加
answer
CHANGED
|
@@ -6,4 +6,96 @@
|
|
|
6
6
|
|
|
7
7
|
都道府県の場合は1対1（←会員が住んでいる都道府県は必ず１つなので）、サイトにたどり着いた経緯なら1対1（←単一選択のみ）か1対多（←複数選択可）になると思います。
|
|
8
8
|
|
|
9
|
-
この場合、モデル自体はテーブルの数分だけ作らなければなりませんが、コントローラーから呼び出す時は、基本的には「会員テーブル」のモデルを呼出し、それ以外の関連テーブルは「会員テーブルモデル」経由で呼び出すことになります。
|
|
9
|
+
この場合、モデル自体はテーブルの数分だけ作らなければなりませんが、コントローラーから呼び出す時は、基本的には「会員テーブル」のモデルを呼出し、それ以外の関連テーブルは「会員テーブルモデル」経由で呼び出すことになります。
|
|
10
|
+
|
|
11
|
+
------------------
|
|
12
|
+
|
|
13
|
+
回答へのコメントを受けて追記。
|
|
14
|
+
|
|
15
|
+
すみません、上記の「リレーション」についての回答は、ご推察のとおり
|
|
16
|
+
> 1会員もしくは複数の会員に紐づくデータを表示させる
|
|
17
|
+
方法となっております。
|
|
18
|
+
|
|
19
|
+
> 選択肢を表示させる方法
|
|
20
|
+
> (都道府県も、サイトにたどり着いた経緯も、
|
|
21
|
+
> テーブルからすべてデータを取得して選択肢としてすべて表示する)
|
|
22
|
+
|
|
23
|
+
につきましては、もし、「都道府県マスタテーブル」と「サイトにたどり着いた経緯マスタテーブル」を持つのであれば、原則に則るのならば、回答へのコメントに書いていただいたように
|
|
24
|
+
|
|
25
|
+
```
|
|
26
|
+
// 都道府県マスタ
|
|
27
|
+
$prefectures = Prefecture::all(); // ←イメージ図。実際は「並べ替え」等の考慮が必要
|
|
28
|
+
|
|
29
|
+
// サイトにたどり着いた経緯マスタ
|
|
30
|
+
$site_visit_reasons = SiteVisitReason::all(); // ←イメージ図。実際は「並べ替え」等の考慮が必要
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
という形で並べることになります。
|
|
34
|
+
|
|
35
|
+
> 使うテーブルの数だけモデルを呼び出してインスタンスを作成するのは、
|
|
36
|
+
> 表示項目が多い場面だと、ズラッと処理が並ぶことになるので、
|
|
37
|
+
> まとめることができるのではないかと思ったことです。
|
|
38
|
+
|
|
39
|
+
まとめたい理由次第かとは思うのですが、以下、想定される理由別に解決案を書いてみます。
|
|
40
|
+
|
|
41
|
+
想定される理由１）コントローラーに並べると可読性が悪くなるから「ユーザーのマスタ取得系」の処理をまとめたい
|
|
42
|
+
|
|
43
|
+
解決案１－１）
|
|
44
|
+
「サービス」という概念を使い、「ユーザーのマスタ取得」を１つのメソッドにしてしまえば、コントローラーはスッキリします。
|
|
45
|
+
[https://qiita.com/minechan1234/items/2cc7c69875fafb2fdae9](https://qiita.com/minechan1234/items/2cc7c69875fafb2fdae9)
|
|
46
|
+
|
|
47
|
+
|
|
48
|
+
解決案１－２）
|
|
49
|
+
もし、「サービスを導入するのはちょっと敷居が高い」ということであれば、コントローラー内のプライベートメソッドに切り出して、「ユーザー用のマスタ情報を１つの変数にまとめる」だけでも十分見やすくなると思います。
|
|
50
|
+
|
|
51
|
+
```
|
|
52
|
+
// ↓とあるコントローラークラスのメソッド
|
|
53
|
+
|
|
54
|
+
public function index()
|
|
55
|
+
{
|
|
56
|
+
// ～略～
|
|
57
|
+
$user_masters = $this->getUserMasters();
|
|
58
|
+
// ～略～
|
|
59
|
+
}
|
|
60
|
+
|
|
61
|
+
/**
|
|
62
|
+
* ユーザーのマスタ情報を取得
|
|
63
|
+
*/
|
|
64
|
+
private function getUserMasters()
|
|
65
|
+
{
|
|
66
|
+
$user_masters = [];
|
|
67
|
+
|
|
68
|
+
// 都道府県マスタ
|
|
69
|
+
$user_masters['prefectures'] = Prefecture::all(); // ←イメージ図。実際は「並べ替え」等の考慮が必要
|
|
70
|
+
|
|
71
|
+
// サイトにたどり着いた経緯マスタ
|
|
72
|
+
$user_masters['site_visit_reasons'] = SiteVisitReason::all(); // ←イメージ図。実際は「並べ替え」等の考慮が必要
|
|
73
|
+
|
|
74
|
+
return $user_masters;
|
|
75
|
+
}
|
|
76
|
+
```
|
|
77
|
+
### 想定される理由２）テーブルにアクセスする回数を減らしたい
|
|
78
|
+
|
|
79
|
+
コードの書き方を工夫したとしても、最終的に「各種テーブルにアクセスしなければならない」という点は変わりません。
|
|
80
|
+
|
|
81
|
+
#### 解決案２－１）
|
|
82
|
+
[https://qiita.com/sakuraya/items/42fffe0f171d49ee74a0#](https://qiita.com/sakuraya/items/42fffe0f171d49ee74a0#)
|
|
83
|
+
のように、DBではなく設定ファイルに定義してしまうと、テーブルへのアクセスは不要になります。
|
|
84
|
+
|
|
85
|
+
なお、設定ファイルに定義した場合、コードの可読性が良くなるだけでなく、無駄なDBアクセスが発生しない＝表示速度も速くなります。
|
|
86
|
+
その代わり、ちょっと選択肢を増やしたいだけの時にも、設定ファイルを修正しなければならなくなります。
|
|
87
|
+
|
|
88
|
+
#### 解決案２－２）
|
|
89
|
+
「DBを使う」という点はそのままで、「会員マスタ系のテーブル」を「都道府県マスタ」「サイトにたどりついた経緯マスタ」で分割するのではなく「会員マスタテーブル」で一元管理すれば、１回のアクセスで複数のマスタ情報がまとめて取得できます。
|
|
90
|
+
|
|
91
|
+
■会員マスタサンプル（category_id=1が都道府県、2がサイトにたどり着いた経緯です）
|
|
92
|
+
|
|
93
|
+
|category_id|branch_id|name|
|
|
94
|
+
|---|---|---|
|
|
95
|
+
|1|1|北海道|
|
|
96
|
+
|1|13|東京都|
|
|
97
|
+
|2|1|検索エンジンから|
|
|
98
|
+
|2|2|知人にすすめられた|
|
|
99
|
+
|
|
100
|
+
⇒解決案として提示しておいて何ですが、この持ち方ですと、DBから取得した後にPHP側で扱いにくくなる＆不測の事態が発生した時に困ります（例：セレクトボックスのvalueにあたる「branch_id」を数字で定義したのに、新項目は文字列にしなければならなくなった）。
|
|
101
|
+
そのため、積極的にはおススメしません。
|