テーブルの列定義に変更があった場合、どうすれば漏れなく修正出来るか

Question

データベースの列定義(名前・属性)の変更(追加・修正・削除)があった場合に、
全ての修正箇所の特定をするためにはどのような工夫や方法を取られていますか？

ちなみに今までに業務で行ってきた方法だと以下の様になりますが、
それでも修正漏れ等はどうしても出してしまうのが実情です。

1. Grepで検索
2. 全ての列を定数などで定義して、エラー箇所や近いものを参照
3. EntityやPOJOといったオブジェクトでテーブル情報を管理する

理想としては一切のSQLを書くことなく実装できることが望ましいのですが、
現状ではなかなかそうもいきません。

また、開発初期段階時などではDB定義の変更はよくあることなので、
そういった場面での工夫などもありましたら、ぜひ教えてください。

Answer 1

基本grepですね。
あとはテストを入念に行う。
結構grepに引っかからなかったところが出てきたりします。

Comments

[iwamoto_takaaki]

よこから質問失礼します。

grepに引っかから無いのはどんなケースでしょうか。聞きたくないけど、聞かない訳にはいかない気分です。

[ttyp03]

過去にSQLServerを使ったシステムの改修のことですが、
ソース管理がいい加減で、あちこちのフォルダに拡散していたりとか。
SSISで使ってたりとか。
grepした人の不注意で、大文字小文字を気にせず検索してたりとか。
まさかバッチファイルでクエリを投げてたりとか。
ジョブで使ってたりとか。

[iwamoto_takaaki]

やっぱりソース管理ですね。
保守の人を陥れようとしているとしか思えない恐ろしい状態ですね。
（引き継ぎ時にソースの分散に気付いて、ヒヤリとしたことがあります。）

grepのミスもまさかですが・・・

[cha-ra]

列定義オブジェクト(列名と同じ)をリストに纏めて、
for文で回してSQL生成したりもよくするのですが、
そういうのも探しにくかったりするのでしょうか。。。

PL/SQLやジョブといったDBに埋め込むタイプのものも、
DDLとしてソース管理していないと思わぬタイミングでエラーが発生したりしますよね。
Javaアプリケーション＋VBメンテナンスみたいなプロジェクトを経験しましたが、
SVNとVSSで別管理となっていたため、どちらか片方は見落とされがちでした。。。

[ttyp03]

動的にSQLを生成してたとしても、通常であればテーブル名で引っかかると思うので大丈夫だと思います。
たまに動的SQLのためにテーブル名をテーブルに持っていてそこからSQLを生成する場合もありますが、そういうのはgrepでは引っかからないので注意が必要ですね。
基本的にはそのシステムに習熟している技術者であれば、どこに何があるかわかっているので見落とすことは稀かと思います。
ありがちなのは、システム改修のために急きょ集めた人たちだと、例外的な処理は見落としがちですね。
設計書なり構成管理なりがきちんとしてれば問題ないのでしょうけどね。

Answer 2

cha-ra さん

初めまして、tomariです。
フォローして頂いたので、回答します。

データベースの列定義(名前・属性)の変更(追加・修正・削除)があった場合に、
全ての修正箇所の特定をするためにはどのような工夫や方法を取られていますか？

→タイミング別に記載します。
○修正前
１）「select 」のようなgrepに引っかからない記述をしない。等
２）カラム名、変数名等の命名規則を作り、grepしやすいようにする。
（他の方参照）
３）grepの時にコメントアウトか分かるように、
コメントアウト「/ */」内に改行を含めない。
４）SQLを１行で書かない。
（修正前後でDIFFが分かりにくい）

○修正後
５）システム全体の設計思想の把握とDB設計思想の把握
６）頭の中で変更による修正箇所・修正内容の特定・影響調査
（悪く言えば俗人性が高い。良く言えば職人技。）
７）grepによる修正箇所の特定の繰り返し
（カラムの値を格納している変数名でもさらにgrep）

○その他コメント等
６）で漏れたら、テストも漏れる。
これを漏らさないためにgrepを行うけれど、
grep結果は自分の頭の中での影響調査と念のための一致確認や
修正したかどうかのチェックリストとして使っている。

修正箇所の特定ができても、修正方法（設計）に問題があればバグる。
可能であれば、第３者チェックをしたいが、
第３者も上記の３）４）を理解出来なければ、意味がない。
第３者が居ない場合の自己チェックは、思い込みを減らすため、
日を空けてチェックや再設計するようにしている。

理想としては一切のSQLを書くことなく実装できることが望ましい

→SQLを書くことなく実装できることが望ましいと思わないのは、
SQLに抵抗がないからかな。

開発初期段階時などではDB定義の変更はよくあることなので、
そういった場面での工夫などもありましたら、ぜひ教えてください。

→初期段階とはいえ、「たまにあること」程度にする。
具体的には、以下の３つ。
１：そもそも仕様変更させない工夫（＝設計前の仕様面の念押し確認）
２：やむを得ない場合でも、既存を引きずる覚悟（＝影響を抑える工夫）
３：先を見通したDB設計（＝機能面だけでなく、性能面・保守面も考慮する）

Comments

[cha-ra]

コメントありがとうございます。
MySQLの性能劣化の回答が、自分にとってとても為になるものだったのでフォローしました！

＞３）grepの時にコメントアウトか分かるように、
＞コメントアウト「/* */」内に改行を含めない。
これはとても大事ですね。
該当箇所を見にいったらコメントでしたなんて場合だと、
コメントを消していい場合ならいいですが、そうでない場合は直してもあまり意味がないので困りますね。

＞５）システム全体の設計思想の把握とDB設計思想の把握
＞６）頭の中で変更による修正箇所・修正内容の特定・影響調査
＞（悪く言えば俗人性が高い。良く言えば職人技。）
この辺りを簡易に出来る仕組みが欲しいところですよね。

＞>理想としては一切のSQLを書くことなく実装できることが望ましい
＞→SQLを書くことなく実装できることが望ましいと思わないのは、
＞SQLに抵抗がないからかな。
SQLを書くのは好きですね、DBの中身はまだまだよくわかってませんが。。。
複雑なSQLはともかく簡易的(IDでSelect・Update・Delete、全件Select)な場合には、
フレームワーク側で書かなくてもいいように出来るのが好きですね。
こういう場合だと select * で記述していれば、POJO側を修正するだけで済むので(IDEでエラー出してくれる)。

Answer 3

私は Grep ですかね。
大文字・小文字無視で検索をかけてひたすらチェックしていく簡単なお仕事…

昔 DAO とか DTO とか使っていた時は、修正箇所がまとまっていたので（DB を触るのは DAO だけ）
多少楽だった気がします。

Comments

[cha-ra]

私はGrepチェックは苦手(そもそも視認作業が苦手)なので、簡単と言えるのが羨ましいです。
DTOがあると新規に列を追加したとしても、別項目を削除or参照の検索することで、
コード上の利用範囲が見えるのがいいですね。

どんな場合でもそうですが、どこか一箇所に纏まっていることが保障されていると、
それだけでコストが下がっていいですよね。

[sk_3122]

あ、「簡単なお仕事」は定型文で
実際は精神力を消費しながらひたすらチェックしていきます ^^;
大文字小文字、後ほんとストアドとかから呼んでないかとか…
大変ですよね;;

Answer 4

データベースの構造を含めて全部出力するコマンドやSQLを使って構造をDDL文にして比較するのが漏れがなさそう。
PostgreSQLだとpg_dumpallとかあるので。

でもこの方法だと「なぜ現行こうなっているのか」っていう経緯説明はわからないので、そういうのは別途ドキュメントベースでの管理とかでしょうか。

Comments

[cha-ra]

しっかりと正規化されている場合等では、全出力して管理する等は良さそうですね。
ただ、dumpと別ドキュメントでとなると、管理先が増える分コストがかかりそうなのも大変そうです。

Answer 5

本質的には仕様書に参照状況を書いておかない限り難しいかも

とくにカラム名を変な連番管理とかしてループでまわしてたりすると
最悪なのでカラム名はきちんと書くようにしたいですね。

個人的には・・・
grepしやすいように、テーブル名に接頭句として「t_」をつけたり
mysqlなどはDB名やtable名をバッククォートで囲む方言があるので
明示的に付加して検索することでマッチしやすくさせています。
（今回のケースだとSQL側では処理したくなさそうなので難しいかな）

Comments

[cha-ra]

テーブル名・列名に接頭/接尾語をつけるのは、該当SQLを探す場面ではとても助かりますね。
その値を受け取って処理する変数やメンバ等も同じように統一出来たら、
コード上の影響範囲もわかりやすそうですね。