既存システムのカスタマイズや、テスト時のバグなどで、複雑なSQLの改造や修正が必要になった時、今でも困ることがあります。
例えば結合テストの段階でSQLににバグが見つかった場合、もともと複雑なSQLや、長いSQL文の修正は時間がかかることがあります。他の開発者が製造した機能の場合、現状のSQL解析だけで、さらに時間がかかります。あまりに修正に時間がかかりそうだった場合、あきらめて、やむなく製造担当者に修正を依頼しなければならないこともあります。(担当者はすでに別プロジェクトにいたりする...)
かといって、長い複雑なSQLを分割し、結果を別々に取得するなどした場合、何度もSQLを発行し、それをまとめるなどの処理が増えるため、保守性が上がることがある「かも」しれませんが、コーディング量が増え、かえって余計なバグの埋め込みや、コストアップになるかもしれません。
一度のSQLで必要な結果がサクッと取得できれば、無駄なコーディングが要らず、システムへの負荷の軽減になります。(SQLの効率や負荷の話もありますが)。
結局、カスタマイズやバグ修正の時間がない場合、土壇場になって、自分のSQLの技術が低いことを棚上げしているだけかもしれません。時間のあるときに、今更ながら、SQLの勉強をしておきたいものです。
以上、現場Yでした。
P.S.
ずいぶん寒くなりました。自宅の庭の、すでに咲き終えたコスモスやケイトウを刈り取り、まとめて処分。今シーズンのぷちガーデニングも終了し、いよいよ冬支度、あっという間の師走です。
例えば結合テストの段階でSQLににバグが見つかった場合、もともと複雑なSQLや、長いSQL文の修正は時間がかかることがあります。他の開発者が製造した機能の場合、現状のSQL解析だけで、さらに時間がかかります。あまりに修正に時間がかかりそうだった場合、あきらめて、やむなく製造担当者に修正を依頼しなければならないこともあります。(担当者はすでに別プロジェクトにいたりする...)
かといって、長い複雑なSQLを分割し、結果を別々に取得するなどした場合、何度もSQLを発行し、それをまとめるなどの処理が増えるため、保守性が上がることがある「かも」しれませんが、コーディング量が増え、かえって余計なバグの埋め込みや、コストアップになるかもしれません。
一度のSQLで必要な結果がサクッと取得できれば、無駄なコーディングが要らず、システムへの負荷の軽減になります。(SQLの効率や負荷の話もありますが)。
結局、カスタマイズやバグ修正の時間がない場合、土壇場になって、自分のSQLの技術が低いことを棚上げしているだけかもしれません。時間のあるときに、今更ながら、SQLの勉強をしておきたいものです。
以上、現場Yでした。
P.S.
ずいぶん寒くなりました。自宅の庭の、すでに咲き終えたコスモスやケイトウを刈り取り、まとめて処分。今シーズンのぷちガーデニングも終了し、いよいよ冬支度、あっという間の師走です。
■[開発現場便り]内の前後の記事
↑ #52 日課
→ #51 SQL
↓ #50 段取り
■更新日時での前後の記事
↑ EeB バドミントンクラブ Vol.82
→ #51 SQL
↓ 今週の育成現場便り(11/24~11/28)
