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