回答編集履歴
2
表示崩れを修正
test
CHANGED
|
@@ -28,8 +28,12 @@
|
|
|
28
28
|
|
|
29
29
|
すみません、上記の「リレーション」についての回答は、ご推察のとおり
|
|
30
30
|
|
|
31
|
+
|
|
32
|
+
|
|
31
33
|
> 1会員もしくは複数の会員に紐づくデータを表示させる
|
|
32
34
|
|
|
35
|
+
|
|
36
|
+
|
|
33
37
|
方法となっております。
|
|
34
38
|
|
|
35
39
|
|
|
@@ -78,11 +82,11 @@
|
|
|
78
82
|
|
|
79
83
|
|
|
80
84
|
|
|
81
|
-
想定される理由１）コントローラーに並べると可読性が悪くなるから「ユーザーのマスタ取得系」の処理をまとめたい
|
|
85
|
+
### 想定される理由１）コントローラーに並べると可読性が悪くなるから「ユーザーのマスタ取得系」の処理をまとめたい
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
|
|
86
|
+
|
|
87
|
+
|
|
88
|
+
|
|
85
|
-
解決案１－１）
|
|
89
|
+
#### 解決案１－１）
|
|
86
90
|
|
|
87
91
|
「サービス」という概念を使い、「ユーザーのマスタ取得」を１つのメソッドにしてしまえば、コントローラーはスッキリします。
|
|
88
92
|
|
|
@@ -92,7 +96,7 @@
|
|
|
92
96
|
|
|
93
97
|
|
|
94
98
|
|
|
95
|
-
解決案１－２）
|
|
99
|
+
#### 解決案１－２）
|
|
96
100
|
|
|
97
101
|
もし、「サービスを導入するのはちょっと敷居が高い」ということであれば、コントローラー内のプライベートメソッドに切り出して、「ユーザー用のマスタ情報を１つの変数にまとめる」だけでも十分見やすくなると思います。
|
|
98
102
|
|
|
@@ -150,6 +154,8 @@
|
|
|
150
154
|
|
|
151
155
|
```
|
|
152
156
|
|
|
157
|
+
|
|
158
|
+
|
|
153
159
|
### 想定される理由２）テーブルにアクセスする回数を減らしたい
|
|
154
160
|
|
|
155
161
|
|
1
回答へのコメントを受けて、回答内容追加
test
CHANGED
|
@@ -15,3 +15,187 @@
|
|
|
15
15
|
|
|
16
16
|
|
|
17
17
|
この場合、モデル自体はテーブルの数分だけ作らなければなりませんが、コントローラーから呼び出す時は、基本的には「会員テーブル」のモデルを呼出し、それ以外の関連テーブルは「会員テーブルモデル」経由で呼び出すことになります。
|
|
18
|
+
|
|
19
|
+
|
|
20
|
+
|
|
21
|
+
------------------
|
|
22
|
+
|
|
23
|
+
|
|
24
|
+
|
|
25
|
+
回答へのコメントを受けて追記。
|
|
26
|
+
|
|
27
|
+
|
|
28
|
+
|
|
29
|
+
すみません、上記の「リレーション」についての回答は、ご推察のとおり
|
|
30
|
+
|
|
31
|
+
> 1会員もしくは複数の会員に紐づくデータを表示させる
|
|
32
|
+
|
|
33
|
+
方法となっております。
|
|
34
|
+
|
|
35
|
+
|
|
36
|
+
|
|
37
|
+
> 選択肢を表示させる方法
|
|
38
|
+
|
|
39
|
+
> (都道府県も、サイトにたどり着いた経緯も、
|
|
40
|
+
|
|
41
|
+
> テーブルからすべてデータを取得して選択肢としてすべて表示する)
|
|
42
|
+
|
|
43
|
+
|
|
44
|
+
|
|
45
|
+
につきましては、もし、「都道府県マスタテーブル」と「サイトにたどり着いた経緯マスタテーブル」を持つのであれば、原則に則るのならば、回答へのコメントに書いていただいたように
|
|
46
|
+
|
|
47
|
+
|
|
48
|
+
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
// 都道府県マスタ
|
|
52
|
+
|
|
53
|
+
$prefectures = Prefecture::all(); // ←イメージ図。実際は「並べ替え」等の考慮が必要
|
|
54
|
+
|
|
55
|
+
|
|
56
|
+
|
|
57
|
+
// サイトにたどり着いた経緯マスタ
|
|
58
|
+
|
|
59
|
+
$site_visit_reasons = SiteVisitReason::all(); // ←イメージ図。実際は「並べ替え」等の考慮が必要
|
|
60
|
+
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
|
|
64
|
+
|
|
65
|
+
という形で並べることになります。
|
|
66
|
+
|
|
67
|
+
|
|
68
|
+
|
|
69
|
+
> 使うテーブルの数だけモデルを呼び出してインスタンスを作成するのは、
|
|
70
|
+
|
|
71
|
+
> 表示項目が多い場面だと、ズラッと処理が並ぶことになるので、
|
|
72
|
+
|
|
73
|
+
> まとめることができるのではないかと思ったことです。
|
|
74
|
+
|
|
75
|
+
|
|
76
|
+
|
|
77
|
+
まとめたい理由次第かとは思うのですが、以下、想定される理由別に解決案を書いてみます。
|
|
78
|
+
|
|
79
|
+
|
|
80
|
+
|
|
81
|
+
想定される理由１）コントローラーに並べると可読性が悪くなるから「ユーザーのマスタ取得系」の処理をまとめたい
|
|
82
|
+
|
|
83
|
+
|
|
84
|
+
|
|
85
|
+
解決案１－１）
|
|
86
|
+
|
|
87
|
+
「サービス」という概念を使い、「ユーザーのマスタ取得」を１つのメソッドにしてしまえば、コントローラーはスッキリします。
|
|
88
|
+
|
|
89
|
+
[https://qiita.com/minechan1234/items/2cc7c69875fafb2fdae9](https://qiita.com/minechan1234/items/2cc7c69875fafb2fdae9)
|
|
90
|
+
|
|
91
|
+
|
|
92
|
+
|
|
93
|
+
|
|
94
|
+
|
|
95
|
+
解決案１－２）
|
|
96
|
+
|
|
97
|
+
もし、「サービスを導入するのはちょっと敷居が高い」ということであれば、コントローラー内のプライベートメソッドに切り出して、「ユーザー用のマスタ情報を１つの変数にまとめる」だけでも十分見やすくなると思います。
|
|
98
|
+
|
|
99
|
+
|
|
100
|
+
|
|
101
|
+
```
|
|
102
|
+
|
|
103
|
+
// ↓とあるコントローラークラスのメソッド
|
|
104
|
+
|
|
105
|
+
|
|
106
|
+
|
|
107
|
+
public function index()
|
|
108
|
+
|
|
109
|
+
{
|
|
110
|
+
|
|
111
|
+
// ～略～
|
|
112
|
+
|
|
113
|
+
$user_masters = $this->getUserMasters();
|
|
114
|
+
|
|
115
|
+
// ～略～
|
|
116
|
+
|
|
117
|
+
}
|
|
118
|
+
|
|
119
|
+
|
|
120
|
+
|
|
121
|
+
/**
|
|
122
|
+
|
|
123
|
+
* ユーザーのマスタ情報を取得
|
|
124
|
+
|
|
125
|
+
*/
|
|
126
|
+
|
|
127
|
+
private function getUserMasters()
|
|
128
|
+
|
|
129
|
+
{
|
|
130
|
+
|
|
131
|
+
$user_masters = [];
|
|
132
|
+
|
|
133
|
+
|
|
134
|
+
|
|
135
|
+
// 都道府県マスタ
|
|
136
|
+
|
|
137
|
+
$user_masters['prefectures'] = Prefecture::all(); // ←イメージ図。実際は「並べ替え」等の考慮が必要
|
|
138
|
+
|
|
139
|
+
|
|
140
|
+
|
|
141
|
+
// サイトにたどり着いた経緯マスタ
|
|
142
|
+
|
|
143
|
+
$user_masters['site_visit_reasons'] = SiteVisitReason::all(); // ←イメージ図。実際は「並べ替え」等の考慮が必要
|
|
144
|
+
|
|
145
|
+
|
|
146
|
+
|
|
147
|
+
return $user_masters;
|
|
148
|
+
|
|
149
|
+
}
|
|
150
|
+
|
|
151
|
+
```
|
|
152
|
+
|
|
153
|
+
### 想定される理由２）テーブルにアクセスする回数を減らしたい
|
|
154
|
+
|
|
155
|
+
|
|
156
|
+
|
|
157
|
+
コードの書き方を工夫したとしても、最終的に「各種テーブルにアクセスしなければならない」という点は変わりません。
|
|
158
|
+
|
|
159
|
+
|
|
160
|
+
|
|
161
|
+
#### 解決案２－１）
|
|
162
|
+
|
|
163
|
+
[https://qiita.com/sakuraya/items/42fffe0f171d49ee74a0#](https://qiita.com/sakuraya/items/42fffe0f171d49ee74a0#)
|
|
164
|
+
|
|
165
|
+
のように、DBではなく設定ファイルに定義してしまうと、テーブルへのアクセスは不要になります。
|
|
166
|
+
|
|
167
|
+
|
|
168
|
+
|
|
169
|
+
なお、設定ファイルに定義した場合、コードの可読性が良くなるだけでなく、無駄なDBアクセスが発生しない＝表示速度も速くなります。
|
|
170
|
+
|
|
171
|
+
その代わり、ちょっと選択肢を増やしたいだけの時にも、設定ファイルを修正しなければならなくなります。
|
|
172
|
+
|
|
173
|
+
|
|
174
|
+
|
|
175
|
+
#### 解決案２－２）
|
|
176
|
+
|
|
177
|
+
「DBを使う」という点はそのままで、「会員マスタ系のテーブル」を「都道府県マスタ」「サイトにたどりついた経緯マスタ」で分割するのではなく「会員マスタテーブル」で一元管理すれば、１回のアクセスで複数のマスタ情報がまとめて取得できます。
|
|
178
|
+
|
|
179
|
+
|
|
180
|
+
|
|
181
|
+
■会員マスタサンプル（category_id=1が都道府県、2がサイトにたどり着いた経緯です）
|
|
182
|
+
|
|
183
|
+
|
|
184
|
+
|
|
185
|
+
|category_id|branch_id|name|
|
|
186
|
+
|
|
187
|
+
|---|---|---|
|
|
188
|
+
|
|
189
|
+
|1|1|北海道|
|
|
190
|
+
|
|
191
|
+
|1|13|東京都|
|
|
192
|
+
|
|
193
|
+
|2|1|検索エンジンから|
|
|
194
|
+
|
|
195
|
+
|2|2|知人にすすめられた|
|
|
196
|
+
|
|
197
|
+
|
|
198
|
+
|
|
199
|
+
⇒解決案として提示しておいて何ですが、この持ち方ですと、DBから取得した後にPHP側で扱いにくくなる＆不測の事態が発生した時に困ります（例：セレクトボックスのvalueにあたる「branch_id」を数字で定義したのに、新項目は文字列にしなければならなくなった）。
|
|
200
|
+
|
|
201
|
+
そのため、積極的にはおススメしません。
|