回答編集履歴
5
誤字修正
answer
CHANGED
@@ -104,7 +104,7 @@
|
|
104
104
|
……と長々と語りはしましたが、
|
105
105
|
結局は列別名の振り方とかも個人の好みの問題の側面が強いのでご自身がやりやすいように、
|
106
106
|
そして**他の方が後々メンテナンスする際に分かりにくくならない**ように、
|
107
|
-
上
|
107
|
+
上記を意識して取り組むと他者が見てケチが付けられにくいコーディングが出来るようになってくるでしょう。
|
108
108
|
|
109
109
|
僕自身も修行中の身ではありますので、偉そうにし過ぎ感MAXですが。
|
110
110
|
|
4
蛇足追加
answer
CHANGED
@@ -43,4 +43,68 @@
|
|
43
43
|
|
44
44
|
ちなみにUNION ALL以外も、
|
45
45
|
**UNION、EXCEPT(OracleはMINUS)、INTERSECT**などの、
|
46
|
-
**集合演算子**の列名については全て同じような振る舞いとなります。
|
46
|
+
**集合演算子**の列名については全て同じような振る舞いとなります。
|
47
|
+
|
48
|
+
###集合演算子利用時の列別名利用について
|
49
|
+
コメントが長くなりそうだったのでこちらで。
|
50
|
+
|
51
|
+
まだまだ半人前の僕の短い経験上ですが、
|
52
|
+
UNIONなどの集合演算子を利用するシーンで、
|
53
|
+
後者(2つ目)のクエリにのみ別名をつけるケースは、
|
54
|
+
あまり見かけた覚えがありません(もしかしたら普通によく使われてるかも)。
|
55
|
+
|
56
|
+
パターンとしては以下の3パターンが多い気がします。
|
57
|
+
0. 前者のクエリだけ別名を明示する
|
58
|
+
0. 前者、後者ともに別名を明示する
|
59
|
+
0. そもそも別名を付けない
|
60
|
+
|
61
|
+
1つ目のパターンは、
|
62
|
+
そもそも1つ目のカラム名に合わせて結果セットの列名が決まるのだから、
|
63
|
+
2つ目の別名指定は冗長という考え方に基づくと思われます。
|
64
|
+
|
65
|
+
2つ目のパターンは、
|
66
|
+
いやいやぱっと見で前者と後者の対応が分からないのはけしからんでしょとか、
|
67
|
+
後から修正する際にカラム名揃ってないとエディタのキーワード検索で引っかからないじゃんとか、
|
68
|
+
可読性と保守性を重視した考え方に基づくと思います。
|
69
|
+
|
70
|
+
3つ目のパターンは、
|
71
|
+
1つ目のクエリのテーブル列名から一切変える必要もないので、
|
72
|
+
わざわざ記載するだけ冗長という考え方に基づくと思われます。
|
73
|
+
|
74
|
+
特に多いのは1つ目、2つ目の書き方だと思うのですが、
|
75
|
+
その理由としてはそもそもUNIONなどの**集合演算子の性質とか利用目的**を考えてもらうと分かるかもしれません。
|
76
|
+
|
77
|
+
UNIONなどでレコードをくっつけるケースというのは、
|
78
|
+
テーブルは異なるけど構造などが共通しているものを、
|
79
|
+
まとめて取得したいという目的が多いと思います。
|
80
|
+
|
81
|
+
こう例えると誤りもあるかもですが、
|
82
|
+
UNIONで束ねて取得することは、
|
83
|
+
オブジェクト指向でいう所の、
|
84
|
+
**特化(派生クラス)・汎化(基底クラス)の関係**を再現しているとも言える部分があります。
|
85
|
+
|
86
|
+
例えばサンプルして掲示されたSQLでは、
|
87
|
+
野菜、フルーツ、お菓子というテーブルというか、
|
88
|
+
食べ物区分による分類がありますよね。
|
89
|
+
|
90
|
+
これらをUNIONで束ねて名称を取得したい場合、
|
91
|
+
列別名を指定しないとカラム名が野菜名となってるのにもかかわらず、
|
92
|
+
その中にはフルーツ名・お菓子名も入ってますという事態になります。
|
93
|
+
|
94
|
+
そこでUNIONで束ねたものは、
|
95
|
+
名称については野菜名じゃなく別名で食物名にしましょうとか、
|
96
|
+
より一般化した列別名を付けることが多いです。
|
97
|
+
(元々全部のカラムがNAMEとかだったら汎化しようにないですがw)
|
98
|
+
|
99
|
+
そういった事情もあり、
|
100
|
+
上記1つ目、2つ目の別名の振り方が多いのかなと個人的には思ってます。
|
101
|
+
(テーブル設計でも実はスーパタイプ、サブタイプというオブジェクト指向的な切り口の考え方がありますが、
|
102
|
+
蛇足が過ぎるので割愛します。)
|
103
|
+
|
104
|
+
……と長々と語りはしましたが、
|
105
|
+
結局は列別名の振り方とかも個人の好みの問題の側面が強いのでご自身がやりやすいように、
|
106
|
+
そして**他の方が後々メンテナンスする際に分かりにくくならない**ように、
|
107
|
+
上司を意識して取り組むと他者が見てケチが付けられにくいコーディングが出来るようになってくるでしょう。
|
108
|
+
|
109
|
+
僕自身も修行中の身ではありますので、偉そうにし過ぎ感MAXですが。
|
110
|
+
|
3
追記
answer
CHANGED
@@ -39,4 +39,8 @@
|
|
39
39
|
, NULL AS "デカルチャー"
|
40
40
|
FROM
|
41
41
|
Bテーブル B
|
42
|
-
```
|
42
|
+
```
|
43
|
+
|
44
|
+
ちなみにUNION ALL以外も、
|
45
|
+
**UNION、EXCEPT(OracleはMINUS)、INTERSECT**などの、
|
46
|
+
**集合演算子**の列名については全て同じような振る舞いとなります。
|
2
追記
answer
CHANGED
@@ -19,4 +19,24 @@
|
|
19
19
|
HOGE、FUGAとなります。
|
20
20
|
|
21
21
|
このようなケースで列別名をつける際は、
|
22
|
-
HOGE、FUGA側の方で列別名を指定すると良いでしょう。
|
22
|
+
HOGE、FUGA側の方で列別名を指定すると良いでしょう。
|
23
|
+
|
24
|
+
###追記
|
25
|
+
カラム数が異常に多かったり、
|
26
|
+
擬似的に作成したNULLを返すカラムが多いケースでは、
|
27
|
+
可読性、保守性の観点から列別名を明示するのは有用です。
|
28
|
+
|
29
|
+
前のサンプルを使うと以下のイメージ
|
30
|
+
```SQL
|
31
|
+
SELECT
|
32
|
+
A.HOGE AS "ヤック"
|
33
|
+
, A.FUGA AS "デカルチャー"
|
34
|
+
FROM
|
35
|
+
Aテーブル A
|
36
|
+
UNION ALL
|
37
|
+
SELECT
|
38
|
+
B.COL1 AS "ヤック"
|
39
|
+
, NULL AS "デカルチャー"
|
40
|
+
FROM
|
41
|
+
Bテーブル B
|
42
|
+
```
|
1
サンプルコード修正
answer
CHANGED
@@ -11,7 +11,7 @@
|
|
11
11
|
UNION ALL
|
12
12
|
SELECT
|
13
13
|
B.COL1
|
14
|
-
,
|
14
|
+
, NULL
|
15
15
|
FROM
|
16
16
|
Bテーブル B
|
17
17
|
```
|