普通のブログ日記

色々書いているが、最近ようやく暇な生活になった。
理由は簡単で仕事が無くなり、現地を離れる事になりそうだから。
来月の仕事の話が聞こえて来ない。無い=無用ではないが、開発者としてスキルを磨いてきた者には運用者の集団とは相容れない部分がある。
運用者は、帰納的な側面からのアプローチが主体。開発者は演繹的である。
最近、運用者の話題はSQLの実行速度であった。
こう書くと1、これだと2という議論が盛り上がっていた。
書き方でスピードが異なる事は周知であるが、開発者的見地からのアプローチでない事で、ガッカリすると共に、来月から仕事を共にしないだろうという予測もあるので、腰が引けてしまった。参加の要請もない茶話会的な原因追求であったため、遠くから見ていただけ。
出来てきたSQLはindexを張ってあるカラムだけを使ったin句のSQLだった。最初のスタート議論はor句が原因までは正しい事だが、結論がindexのあるカラムだけのSQLではね！
落としたカラムのselectはどうするの？
業務の事が推測される部分は書けないので少し曖昧になるが要件は次の様。
指定された電話番号の存在確認だが、以前のデータが削除されているの事を示す、所謂、生きフラグも考慮するという事だったはず。
良く検討すれば、設計では考慮されなかった事かもしれないが、
生きていない物がある場合は新たな行が追加されている。
つまり2行以上の検索結果では存在するとしてよい。
生きていない物だけで新たな行が無い場合は、そもそも対象電話番号存在確認まで来ない。という思い込みでSQLを書き直していた。

設計の不備を補ったという言い方？なのだろうか？
では、生きフラグは不要？電話番号が再割当された頃にバグとなるだろう。それまでの寿命がアプリに無いことを祈るだけだね。

SQLはindexのあるカラムだけならin句でなくても同等。
不要としたカラムの条件を落とすだけなのでコーディングも楽だったはず。自分の仕事を増やす。テストも、本来なら、全部やり直しのはずだが運用者のPDには参加したくないね。