回答編集履歴
14
推敲
answer
CHANGED
|
@@ -26,5 +26,5 @@
|
|
|
26
26
|
ORDER BY 好きな並び順を記載
|
|
27
27
|
```
|
|
28
28
|
この例での主なチューニングは条件部分のSQLになります。
|
|
29
|
-
状況によって相関によるExistsを使用するなどもありますが、条件として分離できてい
|
|
29
|
+
状況によって相関によるExistsを使用するなどもありますが、条件として分離できていますから、
|
|
30
30
|
駆動表が団体であるので、サブクエリーではなく、join してwhere条件とする方が良いかと思います。
|
13
訂正
answer
CHANGED
|
@@ -12,12 +12,11 @@
|
|
|
12
12
|
取得と条件を分離する事によって、取得や条件一方のみでのテーブル参照なども可能で、変更があっても極端な性能劣化となりにくいのです。
|
|
13
13
|
|
|
14
14
|
質問の内容で考えると以下の様になります。
|
|
15
|
-
※団体IDが団体のプライマリーだと想定。
|
|
15
|
+
※団体IDが団体のプライマリーだと想定。
|
|
16
16
|
```SQL
|
|
17
17
|
SELECT 出したい項目１, 出したい項目２,・・・
|
|
18
|
-
FROM 団体
|
|
18
|
+
FROM 団体
|
|
19
|
-
on t1.団体ID=t2.団体ID
|
|
20
|
-
WHERE
|
|
19
|
+
WHERE 団体ID IN ( -- 条件用SQL
|
|
21
20
|
SELECT distinct t1.団体ID
|
|
22
21
|
FROM 団体 t1 left join 作品 t2
|
|
23
22
|
on t1.団体ID=t2.団体ID
|
12
追記
answer
CHANGED
|
@@ -27,4 +27,5 @@
|
|
|
27
27
|
ORDER BY 好きな並び順を記載
|
|
28
28
|
```
|
|
29
29
|
この例での主なチューニングは条件部分のSQLになります。
|
|
30
|
-
状況によって相関によるExistsを使用するなど
|
|
30
|
+
状況によって相関によるExistsを使用するなどもありますが、条件として分離できているますから、
|
|
31
|
+
駆動表が団体であるので、サブクエリーではなく、join してwhere条件とする方が良いかと思います。
|
11
追記
answer
CHANGED
|
@@ -11,7 +11,8 @@
|
|
|
11
11
|
とはいえ、これが最速になる場合もあります。
|
|
12
12
|
取得と条件を分離する事によって、取得や条件一方のみでのテーブル参照なども可能で、変更があっても極端な性能劣化となりにくいのです。
|
|
13
13
|
|
|
14
|
-
質問の内容で考えると以下の様になります。
|
|
14
|
+
質問の内容で考えると以下の様になります。
|
|
15
|
+
※団体IDが団体のプライマリーだと想定。冗長さの例として取得部分に作品も追加しています。
|
|
15
16
|
```SQL
|
|
16
17
|
SELECT 出したい項目１, 出したい項目２,・・・
|
|
17
18
|
FROM 団体 t1 left join 作品 t2
|
10
追記
answer
CHANGED
|
@@ -16,7 +16,7 @@
|
|
|
16
16
|
SELECT 出したい項目１, 出したい項目２,・・・
|
|
17
17
|
FROM 団体 t1 left join 作品 t2
|
|
18
18
|
on t1.団体ID=t2.団体ID
|
|
19
|
-
WHERE t1.団体ID IN (
|
|
19
|
+
WHERE t1.団体ID IN ( -- 条件用SQL
|
|
20
20
|
SELECT distinct t1.団体ID
|
|
21
21
|
FROM 団体 t1 left join 作品 t2
|
|
22
22
|
on t1.団体ID=t2.団体ID
|
9
推敲
answer
CHANGED
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
表示を目的とする場合に、お薦めしたいSQLの組み立て方は、
|
|
1
|
+
**表示を目的**とする場合に、お薦めしたいSQLの組み立て方は、
|
|
2
2
|
・条件は取得したい集合の駆動表のプライマリーキーだけにする
|
|
3
3
|
です。
|
|
4
4
|
|
8
追記
answer
CHANGED
|
@@ -24,4 +24,6 @@
|
|
|
24
24
|
AND ここに団体に関する色んな条件を記載
|
|
25
25
|
)
|
|
26
26
|
ORDER BY 好きな並び順を記載
|
|
27
|
-
```
|
|
27
|
+
```
|
|
28
|
+
この例での主なチューニングは条件部分のSQLになります。
|
|
29
|
+
状況によって相関によるExistsを使用するなど。
|
7
追記
answer
CHANGED
|
@@ -9,7 +9,7 @@
|
|
|
9
9
|
|
|
10
10
|
これは、苦労してチューニングを行った後の変更で、また苦労のやり直しになる事を改善する目的で行き着いた、**最速ではなく安定を目的**としたものです。
|
|
11
11
|
とはいえ、これが最速になる場合もあります。
|
|
12
|
-
取得と条件を分離する事によって、変更があっても極端な性能劣化となりにくいのです。
|
|
12
|
+
取得と条件を分離する事によって、取得や条件一方のみでのテーブル参照なども可能で、変更があっても極端な性能劣化となりにくいのです。
|
|
13
13
|
|
|
14
14
|
質問の内容で考えると以下の様になります。(団体IDが団体のプライマリーだと想定）
|
|
15
15
|
```SQL
|
6
推敲
answer
CHANGED
|
@@ -8,7 +8,8 @@
|
|
|
8
8
|
勿論、取得する集合と条件の集合を分離するので、冗長さを感じる記述にはなりますが、安定した抽出速度を得る事が出来ます。
|
|
9
9
|
|
|
10
10
|
これは、苦労してチューニングを行った後の変更で、また苦労のやり直しになる事を改善する目的で行き着いた、**最速ではなく安定を目的**としたものです。
|
|
11
|
+
とはいえ、これが最速になる場合もあります。
|
|
11
|
-
|
|
12
|
+
取得と条件を分離する事によって、変更があっても極端な性能劣化となりにくいのです。
|
|
12
13
|
|
|
13
14
|
質問の内容で考えると以下の様になります。(団体IDが団体のプライマリーだと想定）
|
|
14
15
|
```SQL
|
5
追記
answer
CHANGED
|
@@ -8,7 +8,7 @@
|
|
|
8
8
|
勿論、取得する集合と条件の集合を分離するので、冗長さを感じる記述にはなりますが、安定した抽出速度を得る事が出来ます。
|
|
9
9
|
|
|
10
10
|
これは、苦労してチューニングを行った後の変更で、また苦労のやり直しになる事を改善する目的で行き着いた、**最速ではなく安定を目的**としたものです。
|
|
11
|
-
※とはいえ、
|
|
11
|
+
※とはいえ、これが最速になる場合もあります。変更があっても極端な性能劣化となりにくいのです。
|
|
12
12
|
|
|
13
13
|
質問の内容で考えると以下の様になります。(団体IDが団体のプライマリーだと想定）
|
|
14
14
|
```SQL
|
4
推敲
answer
CHANGED
|
@@ -8,6 +8,7 @@
|
|
|
8
8
|
勿論、取得する集合と条件の集合を分離するので、冗長さを感じる記述にはなりますが、安定した抽出速度を得る事が出来ます。
|
|
9
9
|
|
|
10
10
|
これは、苦労してチューニングを行った後の変更で、また苦労のやり直しになる事を改善する目的で行き着いた、**最速ではなく安定を目的**としたものです。
|
|
11
|
+
※とはいえ、MySQL以外ではこれが最速になるものもありますが。
|
|
11
12
|
|
|
12
13
|
質問の内容で考えると以下の様になります。(団体IDが団体のプライマリーだと想定）
|
|
13
14
|
```SQL
|
3
追記
answer
CHANGED
|
@@ -7,6 +7,8 @@
|
|
|
7
7
|
また、条件をプライマリーキーのみとする事により、取得したい集合と条件の集合に分離されるので、チューニングも施しやすくなります。
|
|
8
8
|
勿論、取得する集合と条件の集合を分離するので、冗長さを感じる記述にはなりますが、安定した抽出速度を得る事が出来ます。
|
|
9
9
|
|
|
10
|
+
これは、苦労してチューニングを行った後の変更で、また苦労のやり直しになる事を改善する目的で行き着いた、**最速ではなく安定を目的**としたものです。
|
|
11
|
+
|
|
10
12
|
質問の内容で考えると以下の様になります。(団体IDが団体のプライマリーだと想定）
|
|
11
13
|
```SQL
|
|
12
14
|
SELECT 出したい項目１, 出したい項目２,・・・
|
2
加筆
answer
CHANGED
|
@@ -10,10 +10,11 @@
|
|
|
10
10
|
質問の内容で考えると以下の様になります。(団体IDが団体のプライマリーだと想定）
|
|
11
11
|
```SQL
|
|
12
12
|
SELECT 出したい項目１, 出したい項目２,・・・
|
|
13
|
-
FROM 団体
|
|
13
|
+
FROM 団体 t1 left join 作品 t2
|
|
14
|
+
on t1.団体ID=t2.団体ID
|
|
14
|
-
WHERE 団体ID IN (
|
|
15
|
+
WHERE t1.団体ID IN (
|
|
15
16
|
SELECT distinct t1.団体ID
|
|
16
|
-
FROM 団体 t1
|
|
17
|
+
FROM 団体 t1 left join 作品 t2
|
|
17
18
|
on t1.団体ID=t2.団体ID
|
|
18
19
|
WHERE ここに作品に関する色んな条件を記載
|
|
19
20
|
AND ここに団体に関する色んな条件を記載
|
1
推敲
answer
CHANGED
|
@@ -1,7 +1,8 @@
|
|
|
1
|
-
お薦めしたいSQLの組み立て方は、
|
|
1
|
+
表示を目的とする場合に、お薦めしたいSQLの組み立て方は、
|
|
2
2
|
・条件は取得したい集合の駆動表のプライマリーキーだけにする
|
|
3
3
|
です。
|
|
4
4
|
|
|
5
|
+
|
|
5
6
|
SQLでの抽出の際、プライマリーキーを条件にするのが最速です。
|
|
6
7
|
また、条件をプライマリーキーのみとする事により、取得したい集合と条件の集合に分離されるので、チューニングも施しやすくなります。
|
|
7
8
|
勿論、取得する集合と条件の集合を分離するので、冗長さを感じる記述にはなりますが、安定した抽出速度を得る事が出来ます。
|