開発をしていると、実現するにあたり複数の手法を取れる場合が多く存在する.
教科書で勉強をしていざ「書いていこう」と思ったとき、たびたびその手法の多さに迷う.
社会人になってから学んだ、データを処理する手法の一つに「ストアドプロシージャ(stored procedure)」がある.
例えば、DataBaseに対してこれまでは
- Select文を書き
- 取得した値を加工し
- Update文を書き
それらを、バックエンドソース上で実現していた。
（JavaとかC#とかね）
Webアプリでもコンソールアプリでも、そういった開発を行おうとするとそう実現するのが自然な流れだと思う.
でもこの取得するデータが複雑になっていったり
データの高度な加工を要求されたり
条件分岐させながらデータを取得したかったり（Where区内で変数を使いたい、とかも含めて）
いまいちだなーと感じてきたりする.
そういうときは、ストアドで実現した方がスマートな上に高速化できたりもする.
一連の処理を整理（設計）することで、煩雑な処理がシンプルにSQLの構文で書けるようになる.
バックエンドでがりがり書いて実現していたものが、ストアドのちょっとしたループや一時テーブルで簡単に実現できると、嬉しい.
（もちろん、ストアドにしてもやっぱり複雑なものもあれば、呼び出しが増えて見通しがわるくなることもある）
そんなこんなで、ストアドで実現するのは結構好きです.
もちろん、基本的なCRUDは適当なFW(Entity Frameworkとか)を使えばとても綺麗そういうのもすき.
そんなわたしが今日、「ストアド使うの？やめたほうがよくない？」な場に遭遇しました.
独立したシステム間の通信を新しく実現させる
そういう実装検討会です.
システム１
Web/APサーバ
DBサーバ
システム２
フロー処理を行う特殊サーバ
DBサーバ
システム１は、システム２のDBサーバに入っているデータを取得したい
＜方法①＞
システム２にAPIサービスを用意してもらいhttpでCallする
＜方法②＞
システム２のDBにストアドを用意してもらいCallする
どちらを選ぶか？は色々な要素を踏まえて検討する.
- どのくらいのサイズのデータなのか
- どの程度の頻度で取得するデータなのか
- レスポンスとか気になる
- 既存ではどちらを採用しているのか
- どちらで実現した方が低コストか
- 実装がものによって違うとかソースが散らかると嫌だったりするもんね
今日改めて認識した要素が
「エラーになったときどうなるの？」
正常なシステム１から、DB障害中のシステム２をCallした結果
＜方法①＞
Sorry設定がされていれば「ただいまメンテナンス中です」など正常な応答値を返してくれる
APサーバは冗長構成を組んでいることが多いし、堅牢性が高いと思う
＜方法②＞
システム１にDB Connection Error が溜まりメモリリークしてしまうなどリスクが考えられる
怖い
システム１の全然関係ない処理にまで影響を及ぼすかもしれない
超怖い
そう、とても怖いことがわかりました。
蜜結合って超怖い
疎結合万歳
運用していく視点がまだまだ足りませんな
おわり。