---

この前、DBの構造をゲロったんですけど、トークン辺りってそのまんまコピーしてるからどうみても冗長なんだよなぁという思いが拭いきれません。
そこで、やはり正規化してサロゲートペアを使って管理するようなスキーマにしようかなぁと思いました。まぁ本来はトークンは毎回新規に発行する仕様だったんですけど、実装してみるとあれなんかビミョくね？って思って、最初のやつをコピーすることにした結果こうなったんですけどね。


つまり、予約データのテーブルに対するIDと、予約IDを別にしてしまう、ということですね。これならURLをIDに含めても何ら問題はありません。
なんでURLをIDに含めるのかっていうと理由が2つありまして、1つはトークン文字列の被りに対する対策、もう1つは純粋にパフォーマンスが向上しそうだからです。文字列にインデックスとかあんまり貼りたくないですし･･････。
トークンはあんだけの長さがあれば重複することはまずないと言えますが、天文学的確率で被る可能性はあります。そうすると、完全にシステムは破綻します。そこでIDで絞り込みをかけることでそのリスクを０に出来るので、やはりIDは使いたいんですよね。


ただ、現状予約データ毎にIDを割り振ってしまったのでころっころIDが変わっちゃうのが問題で、そこで「予約ID」と「データのID」を分けることでこの問題の解決はできそうです。
また、こうすることのメリットも実は他にもありまして、読み込むべきデータは常に1つという論理的な構造を物理的に実現できるということです。つまり、is_enableとかいうフラグが不要になりますね。
というのも、予約テーブルに「最新データのID」というのが必然的に入る(つまりこれがサロゲートペアなんですけど)、ので、そこで保証されるわけですね。
変更拒否によるロールバックは、データIDの方のbefore_changeカラムを読み出せば書き戻し可能です。



ということで、こういうロジックに組み直したく、設計してみました。





でまぁ、予定調和というか、結局めんどくさくなってまた突貫工事を始めたんですが、ほんとこの悪癖どうにかならないんですかね･･････。今回もやっぱだめだった･･････。
というか、設計したつもりなんですけど結局ちゃんと設計できていないことに書き始めて気づきっていう。


でも正直な話、一人で開発してる時って、普通に打ち込んだ方が早いっちゃ早いからそっちに逃げちゃうんですよね･･････。
まぁこうやって同じ失敗を繰り返して、そのうち学べたらいいっすね。（）




<<コメントお返事>>

---

>>あいうぇえ さん