回答編集履歴

5

誤字修正

2016/08/03 13:09

投稿

Panzer_vor
Panzer_vor

スコア1636

test CHANGED
@@ -210,7 +210,7 @@
210
210
 
211
211
  そして**他の方が後々メンテナンスする際に分かりにくくならない**ように、
212
212
 
213
- を意識して取り組むと他者が見てケチが付けられにくいコーディングが出来るようになってくるでしょう。
213
+ を意識して取り組むと他者が見てケチが付けられにくいコーディングが出来るようになってくるでしょう。
214
214
 
215
215
 
216
216
 

4

蛇足追加

2016/08/03 13:08

投稿

Panzer_vor
Panzer_vor

スコア1636

test CHANGED
@@ -89,3 +89,133 @@
89
89
  **UNION、EXCEPT(OracleはMINUS)、INTERSECT**などの、
90
90
 
91
91
  **集合演算子**の列名については全て同じような振る舞いとなります。
92
+
93
+
94
+
95
+ ###集合演算子利用時の列別名利用について
96
+
97
+ コメントが長くなりそうだったのでこちらで。
98
+
99
+
100
+
101
+ まだまだ半人前の僕の短い経験上ですが、
102
+
103
+ UNIONなどの集合演算子を利用するシーンで、
104
+
105
+ 後者(2つ目)のクエリにのみ別名をつけるケースは、
106
+
107
+ あまり見かけた覚えがありません(もしかしたら普通によく使われてるかも)。
108
+
109
+
110
+
111
+ パターンとしては以下の3パターンが多い気がします。
112
+
113
+ 0. 前者のクエリだけ別名を明示する
114
+
115
+ 0. 前者、後者ともに別名を明示する
116
+
117
+ 0. そもそも別名を付けない
118
+
119
+
120
+
121
+ 1つ目のパターンは、
122
+
123
+ そもそも1つ目のカラム名に合わせて結果セットの列名が決まるのだから、
124
+
125
+ 2つ目の別名指定は冗長という考え方に基づくと思われます。
126
+
127
+
128
+
129
+ 2つ目のパターンは、
130
+
131
+ いやいやぱっと見で前者と後者の対応が分からないのはけしからんでしょとか、
132
+
133
+ 後から修正する際にカラム名揃ってないとエディタのキーワード検索で引っかからないじゃんとか、
134
+
135
+ 可読性と保守性を重視した考え方に基づくと思います。
136
+
137
+
138
+
139
+ 3つ目のパターンは、
140
+
141
+ 1つ目のクエリのテーブル列名から一切変える必要もないので、
142
+
143
+ わざわざ記載するだけ冗長という考え方に基づくと思われます。
144
+
145
+
146
+
147
+ 特に多いのは1つ目、2つ目の書き方だと思うのですが、
148
+
149
+ その理由としてはそもそもUNIONなどの**集合演算子の性質とか利用目的**を考えてもらうと分かるかもしれません。
150
+
151
+
152
+
153
+ UNIONなどでレコードをくっつけるケースというのは、
154
+
155
+ テーブルは異なるけど構造などが共通しているものを、
156
+
157
+ まとめて取得したいという目的が多いと思います。
158
+
159
+
160
+
161
+ こう例えると誤りもあるかもですが、
162
+
163
+ UNIONで束ねて取得することは、
164
+
165
+ オブジェクト指向でいう所の、
166
+
167
+ **特化(派生クラス)・汎化(基底クラス)の関係**を再現しているとも言える部分があります。
168
+
169
+
170
+
171
+ 例えばサンプルして掲示されたSQLでは、
172
+
173
+ 野菜、フルーツ、お菓子というテーブルというか、
174
+
175
+ 食べ物区分による分類がありますよね。
176
+
177
+
178
+
179
+ これらをUNIONで束ねて名称を取得したい場合、
180
+
181
+ 列別名を指定しないとカラム名が野菜名となってるのにもかかわらず、
182
+
183
+ その中にはフルーツ名・お菓子名も入ってますという事態になります。
184
+
185
+
186
+
187
+ そこでUNIONで束ねたものは、
188
+
189
+ 名称については野菜名じゃなく別名で食物名にしましょうとか、
190
+
191
+ より一般化した列別名を付けることが多いです。
192
+
193
+ (元々全部のカラムがNAMEとかだったら汎化しようにないですがw)
194
+
195
+
196
+
197
+ そういった事情もあり、
198
+
199
+ 上記1つ目、2つ目の別名の振り方が多いのかなと個人的には思ってます。
200
+
201
+ (テーブル設計でも実はスーパタイプ、サブタイプというオブジェクト指向的な切り口の考え方がありますが、
202
+
203
+ 蛇足が過ぎるので割愛します。)
204
+
205
+
206
+
207
+ ……と長々と語りはしましたが、
208
+
209
+ 結局は列別名の振り方とかも個人の好みの問題の側面が強いのでご自身がやりやすいように、
210
+
211
+ そして**他の方が後々メンテナンスする際に分かりにくくならない**ように、
212
+
213
+ 上司を意識して取り組むと他者が見てケチが付けられにくいコーディングが出来るようになってくるでしょう。
214
+
215
+
216
+
217
+ 僕自身も修行中の身ではありますので、偉そうにし過ぎ感MAXですが。
218
+
219
+
220
+
221
+

3

追記

2016/08/03 12:48

投稿

Panzer_vor
Panzer_vor

スコア1636

test CHANGED
@@ -81,3 +81,11 @@
81
81
  Bテーブル B
82
82
 
83
83
  ```
84
+
85
+
86
+
87
+ ちなみにUNION ALL以外も、
88
+
89
+ **UNION、EXCEPT(OracleはMINUS)、INTERSECT**などの、
90
+
91
+ **集合演算子**の列名については全て同じような振る舞いとなります。

2

追記

2016/08/03 03:19

投稿

Panzer_vor
Panzer_vor

スコア1636

test CHANGED
@@ -41,3 +41,43 @@
41
41
  このようなケースで列別名をつける際は、
42
42
 
43
43
  HOGE、FUGA側の方で列別名を指定すると良いでしょう。
44
+
45
+
46
+
47
+ ###追記
48
+
49
+ カラム数が異常に多かったり、
50
+
51
+ 擬似的に作成したNULLを返すカラムが多いケースでは、
52
+
53
+ 可読性、保守性の観点から列別名を明示するのは有用です。
54
+
55
+
56
+
57
+ 前のサンプルを使うと以下のイメージ
58
+
59
+ ```SQL
60
+
61
+ SELECT
62
+
63
+ A.HOGE AS "ヤック"
64
+
65
+ , A.FUGA AS "デカルチャー"
66
+
67
+ FROM
68
+
69
+ Aテーブル A
70
+
71
+ UNION ALL
72
+
73
+ SELECT
74
+
75
+ B.COL1 AS "ヤック"
76
+
77
+ , NULL AS "デカルチャー"
78
+
79
+ FROM
80
+
81
+ Bテーブル B
82
+
83
+ ```

1

サンプルコード修正

2016/08/02 23:38

投稿

Panzer_vor
Panzer_vor

スコア1636

test CHANGED
@@ -24,7 +24,7 @@
24
24
 
25
25
  B.COL1
26
26
 
27
- , A.COL2
27
+ , NULL
28
28
 
29
29
  FROM
30
30