■

設計のレビュー第2弾。マスタメンテナンス画面でマスタの状態を変更(使用可→不可)するとき、既に使われてるかどうかチェックしてから更新するまでの間に別プログラムで更新入ると困るよねって話が。困るよねって話は既に出していて、とりあえず俺が持っているアイディアは更新されると困る方(在庫のデータのテーブル)に表ロックをかけるってのと、ロックテーブルを用意するってのの2案があるんだけど、どうにも気に入ってもらえない。確かに在庫にうっかり表ロックかけてそのままどうにかなっちゃうとシステムが全部止まっちゃうわけで、これを避けたいのはわかる。んで、ロックテーブルが必要なのはここだけ(マスタの削除とか基本的に発生しないから)なので、わざわざロックテーブルを用意するのもダサい実装な感じで難色を示されている。
んで、その場で適当に考えて、各トランザクションで更新前と更新後でSELECTかけて結果が一致しなかったらrollbackとかどうとか言ったらそれが採用になってしまったorz。いや、たぶんそれなんか見落としてるから。それで絶対大丈夫だからと言われてもなあ。確かに現実には俺が懸念してるような状態は起きないと思うんだけど、理論上問題が発生しうることがわかってるのを放置するのーって感じなんだけど。いや、可能性を認識して、万が一の対処法が見えてるなら良いんだけどさー。どうもそういう風に見えないんだよなあ。まあ不整合が起きたからって大した問題になるわけじゃないし、対処法をQ&Aにでも書いておけば良いか。そもそもせっかくマスタ系のテーブルを分離したんだから、他のところでなんかやってるときに変更するなって話だ。いやでもそれですむならわざわざ2度読みするような余計なコストを払うべきじゃないんだよ。参照系のコストを減らすためにこんな複雑な(更新系はタイミングとか考えないといけないケースが多いので)つくりにしたんだからさー。
あとはまあこのときどうなるのみたいな話でいろいろ盛り上がったりしたので、半分終わらすのに5時間くらい。続きは日曜だってさーorz。
なんか会社帰りに飲みに行くことになったので1回休み。しかも俺以外の参加者は全員明日休む予定だっていうんですよもうね。