排他制御、確実なのは「二股交際」

－以降、セクハラの内容を多分に含みますので、そのような内容を嫌う女性の方は、読まないでください－

昨日の、

トランザクションの矛盾回避－なぜ昔DBのテーブル名が数字だったか－
http://blog.goo.ne.jp/xmldtp/e/c77583b1d65c4accd6c8a040efb86f09

に関連したことが、日経System　２０１５年１２月号の９ページ

　RDBの真のメリットは？

にあったので、ついでにひとこと。

---

そこでは、一貫性の話として、INSERT ONLYの場合
（は昨日書いたようにINSERTでの矛盾回避は難しい）
先に子レコードから書くという話が載っていた。

でも、これでも問題が残ることがある。
入荷（＝納品）の場合を考えると、

　　納品票＝親データ
　　納品明細（各商品）＝子データ

となる。
在庫数を見たい＝入庫数をしらべるとき、
納品明細から書かれてしまうと、納品明細を書いている
途中、たとえばA,B,Cという商品が納入され、この順番で
更新するとき、A商品更新後に検索がかかると、AとBC間
で矛盾したものが検索されてしまう。
かといって、コレを防ぐ為に、親レコード（納品レコード）
が存在するかと常に聞くのは、無駄が大きい。

---

このことが、昔、問題になったことがある。

当時は、前回のように、入荷出荷の問題で、かつ、
在庫確認から、出庫まで時間がかかり、その間に
変化する可能性が大きい場合だった。

で、そのケースではどうしたか？
（その前に、すでに入る順番とかは決めてある）

誰かが思いついた・・・
（当時はセクハラなどという概念はない）
二股、三股交際すればいいんじゃない？

結婚したい相手が３人いたとする。
で、その子たちをキープしながら
（当時はこういう言い方をしたのだ）
結婚相手を１人に絞る場合・・・

３人と付き合って、つばつけておく（とそいつは言った）
そうすれば、最後に自分の気に入った１人と結婚した瞬間に
２人はフリーと、第三者は分かる。仮に当人に連絡しなくても・・・

？？？

---

つまり、DBに言い直すと、こうだ。

１．検索した時点なり、更新したい時点なり、
　ともかく、更新する可能性が起こった時点で、
　更新したい人（端末）のIDを「更新予約」という
　項目に入れておく

　　前の例だと、納品書テーブル、入庫テーブル
　　を含む全テーブルに「変更予約」という項目があり

　　納品書に新規納品レコードを、
　　入庫テーブルで商品A,B,Cの各レコードを入出庫数０で、
　　「変更予約」に自分のIDを入れて更新する。

※これが、つばつけておく（二股、三股交際）に相当

２．「更新予約」がある場合、それ相応の処理をする
　　更新されそうなレコードがある場合、どういう対応を
　　するかはさまざま。
　　ただし、一度更新予約されたレコードは、
　　自分が再度更新予約してはならない。

※交際していれば、他のやつは手を出さないだろうということ

３．実際に更新する時は、
　　・更新予約情報に自分が見たときと変化があれば、
　　　　→その間に誰かが操作した
　　　　→データ矛盾。トランザクションキャンセル

※タッチの差で手の早いやつに略奪婚された場合の回避

　　・更新予約情報に変化が無ければ
　　　　　実際に行いたい更新を行う
　　　　　更新予約レコードの予約を解除する
　　　　　　　例えば、更新予約レコードを更新予約をクリアする
　　　　　　　もしくは(INsert ONLYのときなど）
　　　　　　　　更新予約に何も入っていないレコードが書かれたら、
　　　　　　　　更新予約が入っているレコードは検索されないなど

　　　前の例だと、納品レコード、入庫レコードに
　　　　数値をいれ、更新予約をクリアして更新

※結婚したことに相当。この場合は、結婚した相手以外に通知した
　場合に相当する（こんなかんじ）


４．かりに、更新予約を修正しないで終了してしまったとする。
　その場合、システム監視をしていて、一定時間たっても更新予約が
　更新されていないレコードがあれば、システムを監視している人が、
　問い合わせるようにする。
　　その結果、更新予約しておく必要がなければ、システム監視者が
　更新予約をクリアする。

※結婚した相手以外に通知しなくてもOKな場合に相当する

---

この提案（念のために言っておく。私ではない）、
世の中的にはどうなんだ？はさておき、
結局、「更新予約」という概念は採用しました。