回答編集履歴
6
推敲
test
CHANGED
@@ -54,10 +54,10 @@
|
|
54
54
|
|
55
55
|
--
|
56
56
|
|
57
|
-
SQLが長大で
|
57
|
+
SQLが長大で解析が困難というなら、整形して見やすくするというのはどうでしょう。
|
58
58
|
|
59
59
|
[SQL 整形ツール 美しいコードが出力できるテキストエディタはどれ?
|
60
60
|
|
61
61
|
](https://style.potepan.com/articles/16725.html)
|
62
62
|
|
63
|
-
|
63
|
+
統一化されるので要件の抽出はやりやすくなると思います。
|
5
追記
test
CHANGED
@@ -47,3 +47,17 @@
|
|
47
47
|
現状でそれが無いなら作るしかありません。
|
48
48
|
|
49
49
|
ER図はリバースできるDBツールを利用して手抜きは出来ますが、要件を抽出してくれるツールは見た事がありません。
|
50
|
+
|
51
|
+
|
52
|
+
|
53
|
+
追記2
|
54
|
+
|
55
|
+
--
|
56
|
+
|
57
|
+
SQLが長大で理解が困難というなら、発想を変えて、整形して見やすくするというのはどうでしょう。
|
58
|
+
|
59
|
+
[SQL 整形ツール 美しいコードが出力できるテキストエディタはどれ?
|
60
|
+
|
61
|
+
](https://style.potepan.com/articles/16725.html)
|
62
|
+
|
63
|
+
若しくは、コーディング規約を設けておくとか。
|
4
推敲
test
CHANGED
@@ -42,7 +42,7 @@
|
|
42
42
|
|
43
43
|
|
44
44
|
|
45
|
-
|
45
|
+
ただ、それら詳細が無くても、元になる(ER図と要件)のしっかりした物があれば何とか出来ると思います。
|
46
46
|
|
47
47
|
現状でそれが無いなら作るしかありません。
|
48
48
|
|
3
推敲
test
CHANGED
@@ -36,7 +36,7 @@
|
|
36
36
|
|
37
37
|
SQLが長くても単純であれば、解析にそれほど時間は要しません。
|
38
38
|
|
39
|
-
時間を要するのはサブクエリー
|
39
|
+
時間を要するのはサブクエリー等で、ネストが深い場合です。
|
40
40
|
|
41
41
|
なので、ネストの深いものから積み上げる形でそれぞれの単位で(ER図、要件)があれば良いかと思います。
|
42
42
|
|
2
追記
test
CHANGED
@@ -44,4 +44,6 @@
|
|
44
44
|
|
45
45
|
まあ、それが無くても、(ER図と要件)のしっかりした物があれば何とか出来ると思います。
|
46
46
|
|
47
|
-
現状でそれが無いなら
|
47
|
+
現状でそれが無いなら作るしかありません。
|
48
|
+
|
49
|
+
ER図はリバースできるDBツールを利用して手抜きは出来ますが、要件を抽出してくれるツールは見た事がありません。
|
1
追記
test
CHANGED
@@ -5,3 +5,43 @@
|
|
5
5
|
|
6
6
|
|
7
7
|
探せばフリーでもツールはありますので。
|
8
|
+
|
9
|
+
|
10
|
+
|
11
|
+
追記
|
12
|
+
|
13
|
+
--
|
14
|
+
|
15
|
+
※コメントから
|
16
|
+
|
17
|
+
> 1000行以上あるSQLがいくつもある場合、SQLを書いた人がいなくなった場合でも他者が対応できるようにしたいのですが、何か良い方法はありませんか?
|
18
|
+
|
19
|
+
|
20
|
+
|
21
|
+
それは保守の為という事ですね。それはプログラマー向けですか?
|
22
|
+
|
23
|
+
処理フローで書いたとして、SQLと直結する訳ではありませんから、それでSQLをメンテしろと言われてもSQLを組む人は結局SQLを解析する事になってしまいます。
|
24
|
+
|
25
|
+
|
26
|
+
|
27
|
+
[SQLの設計に必要な4つの手順とは?わかりやすい図を使って解説!](https://www.sejuku.net/blog/106593)
|
28
|
+
|
29
|
+
SQLを作成するにあたって必要な資料は、**ER図**と**要件**です。
|
30
|
+
|
31
|
+
(ER図にはテーブルの定義も含みます)
|
32
|
+
|
33
|
+
これらが変更になる時にメンテナンスが発生する訳ですが、その際に対象のSQLの構造が説明としてあれば、メンテナンスはし易くなるでしょう。
|
34
|
+
|
35
|
+
|
36
|
+
|
37
|
+
SQLが長くても単純であれば、解析にそれほど時間は要しません。
|
38
|
+
|
39
|
+
時間を要するのはサブクエリーによるネストが深い場合です。
|
40
|
+
|
41
|
+
なので、ネストの深いものから積み上げる形でそれぞれの単位で(ER図、要件)があれば良いかと思います。
|
42
|
+
|
43
|
+
|
44
|
+
|
45
|
+
まあ、それが無くても、(ER図と要件)のしっかりした物があれば何とか出来ると思います。
|
46
|
+
|
47
|
+
現状でそれが無いなら、手抜きせずに作るしかありませんけども。
|