過去の苦労話・第16回：全部持つな。違うとこだけ登録しろ
■ 全部持つな。違うとこだけ登録しろ
—— 30万件単価マスタで学んだ設計の話
■ プロローグ
商品は30万件。得意先はおよそ500社。
今なら、CSSで「差分だけ上書き」するように、あるいはCRMで「デフォルトを継承」するように、スマートに書けるのかもしれない。
だが、私がその巨大なマトリックスと向き合っていた頃、そんな都合のいい仕組みはなかった。
「得意先ごとに全商品の単価マスタを作ればいい」
若手や外注先は、あっさりそう言った。
全部持つ？ —— 1億5,000万レコードだぞ。
メンテナンス不能な箱を作るのが設計か。
私は首を振った。
現場のルールは、もっと単純だった。
違うとこだけ登録しろ。
■ 第1章：1億5,000万行の幻想と、終わらないバッチ
30万アイテム × 500得意先。
物理的に展開すれば、データの海に溺れるのは目に見えていた。
商品のベース価格が1円変わるたびに、500件の得意先レコードを更新する？
1秒に1,000件書き換えても、終わる頃には次の日が始まっている。
「データを持つ」ということは、「更新し続ける責任を持つ」ということだ。
更新できないデータは、ゴミと同じだ。
■ 第2章：まずはまとめる —— 単価グループという発想
30万件の商品は、30万通りじゃない。
商品は属性で束ねられる。
カテゴリ、メーカー、価格帯。
だから商品には「単価グループ」を持たせた。
さらに、得意先もまたグループでまとめる。
番外、少し大事、もうちょっと大事、とっても大事。
今思えば雑な分け方だが、後から気づく。
本当に分けるべきだったのは「重要度」ではなく「業態」だった。
小売なのか、納品（御用聞き）なのか。
単価は、商品だけでは決まらない。
誰に売るかで決まる。
商品は単価グループを持ち、得意先もグループを持つ。
単価は、その組み合わせで決まる。
■ 第3章：参照という設計 —— 単価は見に行くもの
単価を持たせるのではなく、「どこを見るか」を持たせた。
得意先には「単価参照得意先CD」を持たせる。
A社はB社の単価を見る、といった具合だ。
ただし多段参照は許さない。
C社 → B社 → A社、と辿れるようにすると、いずれ誰も追えなくなる。
だから参照は1段まで。
単価はデータとして“ある”のではなく、
関係として“たどれる”ようにした。
■ 第4章：それでも足りない —— 得意先商品という例外
それでも現実はきれいに収まらない。
特定の商品だけ、この得意先には特別価格。
だから「得意先商品」というレイヤーを用意した。
例外は、例外として持つ。
すべてを例外にしないために。
■ 第5章：単価は持つものじゃない。見つけるものだ
完成された単価を全部並べる必要はない。
必要なその瞬間に、条件をたどって見つければいい。
個別例外はあるか
参照先得意先の単価はあるか
得意先グループの単価はあるか
商品マスタの標準単価か
上から順に潰していく。
見つかるまで、ひたすら探す。
単価は1つじゃない。
だから、持つのではなく、見つけにいく設計にした。
■ 第6章：ロジックは増殖する
基幹はVB、情報系はRuby。
支店には基幹端末がない。
だから情報系でも同じ計算をするしかなかった。
同じロジックを、VBで書き、Rubyで書き直す。
本社のイントラサーバは誰でも見られる。
VPNの向こうの拠点も、そこを見る。
でも、VPN同士は直接話せない。
みんな同じものを見ているのに、
計算ロジックだけが、別々に存在していた。
ロジックは、使われる場所に生まれる。
■ 第7章：そしてロジックは戻ってくる
これは、基幹がCOBOLからoracleに変わってタイミングでロジックをSQL（ストアド）
で作成されたので、これを使うことにした、情報系のSQLでストアド叩いて、単価取得ｗ
ロジックは、データのそばへ戻る。
■ 第8章：ネットワークは分けられたが
基幹、情報系、VPN。
ネットワークはきれいに分けた。
つなぐ場所と、守る場所を分けた。
でも、単価は分けられなかった。
正しい単価は基幹にあった。
でも、みんなが見ていたのはイントラのサーバだった。
ロジックは、その境界を越えてきた。
■ エピローグ
今は簡単につながる時代だ。
Slack を入れれば、誰とでも会話できる。
でも、問題は変わっていない。
どこで計算するか。
どこを正とするか。
回線は簡単になった。
でも、設計は簡単になっていない。
あの頃と同じだ。
全部持つな。
違うとこだけ登録しろ。
なんか、一部誤解されたけど大筋あってるので、AIの提示のまま
コメント